Defensive use · authorization is a separate fact

Cyber-Capable AI: Authority Before Capability

A capable model and an eligible account still do not authorize activity against a target. Make scope, permissions and human control explicit before a defensive test.

Direct answer

For defensive cyber work, record written authority over the exact target and activity, isolate the test, separate read/propose/commit/deploy permissions, protect secrets, require human approval for material actions and preserve a stop and incident path. This is an operational guide, not an adopted policy or safe harbor.

Cyber-capable AI authorization path from written authority through sandbox, target scope, credentials, human approval and stop record
Decision map. Provider access does not grant authority over a target or system.

Start with written authority

Name the legal entity, operator, target, systems, repositories, environments, dates and permitted activity. Keep the authorization separate from model access or a vendor program invitation. A trusted-access route can narrow provider safeguards; it cannot grant authority over a third party’s infrastructure.

Isolate the first run

Use a sandbox or test environment that the organization owns or is authorized to test. Restrict network and tool access, credentials, data classes and destinations. Begin with read access and a non-sensitive canary. Record what the model could see and what it was prevented from doing.

Separate action levels

LevelMeaningControl
ReadInspect approved code or evidenceAllowlist and audit record
ProposeSuggest finding or patchHuman reproduction and review
CommitWrite to a branch or workspaceNamed approval and CI
DeployChange a live environmentSeparate human release authority

Keep a human decision at the edge

Require a person to reproduce a finding, inspect a proposed patch, approve a disclosure and decide whether a change can move forward. Do not let a model’s benchmark result stand in for authorization, review or evidence of safety.

Preserve stop and incident records

Define automatic and human stop conditions: scope drift, credential exposure, unexpected target access, failed tests, tool denial bypass, third-party impact or an unexplained model action. Preserve the run identifier, commands or tool calls, approvals, diffs, tests, disclosures and owner. Escalation and notification depend on the event, contract, client and jurisdiction.

Reopen after capability or route changes

Reopen the authority file when the model, account, tool, target, data, safeguard or provider program changes. A new capability may require a narrower scope even when the business purpose is unchanged.

FAQ

Does access to a cyber model authorize testing?

No. Provider access and authority over a target are separate facts.

Can an acceptable-use guide replace legal review?

No. It can make boundaries explicit; counsel and the responsible security owner adapt it to the jurisdiction, authorization and organization.

Should a capable model receive deploy access?

Do not assume so. Separate read, propose, commit and deploy permissions and require human release authority.

Sources checked

Operational information, not legal advice. Verify current terms, account configuration and applicable professional duties before use.

Decision frame · source-linked

For defensive cyber work, record written authority over the exact target and activity, isolate the test, separate read/propose/commit/deploy permissions, protect secrets, require human approval for material actions and preserve a stop and incident path.

Why now. A compact, source-linked frame makes the next decision portable without replacing the full analysis.

  • Written authority
  • Sandbox
  • Target scope

Take this frame with you

Share the decision, not a generic object. The full sources and limits stay on the canonical page.