00Field guide / agent security
Secure AI Coding Agents: A Practical Control Model
A coding agent combines untrusted instructions, repository content, generated code, tools, and credentials. Security comes from enforceable boundaries around that combination, not from asking the model to be careful.
01Threat model
Assume instructions, dependencies, generated code, and outputs can all be hostile.
Repository text can contain prompt injection. A dependency can execute a lifecycle script. Generated code can read outside its workspace, open a network connection, or produce misleading test output. An error path can accidentally serialize a credential. The threat model needs to include the complete agent loop rather than treating only the model response as untrusted.
The assets at risk include source code, customer material, credentials, build provenance, infrastructure access, money, and the integrity of the evidence used to approve a release. A useful threat model maps each asset to the capability that could reach it and the boundary that prevents or records that access.
- Prompt and repository-content injection
- Malicious or compromised dependencies
- Path traversal and workspace escape
- Credential disclosure through logs, errors, or artifacts
02Authority
Separate the power to execute from the power to accept or release.
A coordinator may be allowed to schedule a test without being allowed to deploy. An implementation agent may write a candidate without being allowed to mark its own acceptance gate as passed. A provider transport may receive an inference key without receiving organization-administration authority. These distinctions need to exist in schemas and runtime checks, not only in policy prose.
Each action should require an explicit capability with scope, limits, and an issuing authority. Cost ceilings, retry counts, model selection, destination, customer-data policy, and publication rights are all security boundaries when an agent can trigger external effects.
- No ambient shared role
- Completion authority is not acceptance authority
- Spending and publishing require explicit confirmation
- Excessively privileged credentials fail before transport
03Isolation
Run candidate code in a fresh tree with explicit mounts and network policy.
A sandbox should materialize the exact candidate into a private boundary, mount only the inputs it requires, and constrain CPU, memory, time, processes, and writes. The host workspace, unrelated repositories, key stores, and production sockets should be absent. Reusing a developer shell with hidden ambient state makes a passing build difficult to reproduce and easy to over-authorize.
Network egress should begin denied. If a build needs a named registry or a browser test needs a local endpoint, grant that route explicitly and retain what was allowed. Network policy is not proved by a prompt instruction or by the absence of an observed request in one run.
- Fresh source-bound candidate tree
- Explicit read and write mounts
- Resource and process limits
- Named egress grants with retained policy
04Credentials
Deliver the narrowest credential at the last responsible moment.
Credentials should live in a private store with restrictive filesystem permissions and remain outside prompts, commits, screenshots, logs, and evidence. The operator should bind a non-secret account alias and policy state during planning, then obtain the actual credential only when a separately authorized transport call is about to occur.
Request construction and failures need adversarial tests. A scanner that runs after execution cannot undo a key printed during an exception. Evidence should prove that raw credentials are absent and should reject administration credentials where only inference authority is needed.
- Project-scoped service credentials
- No key values in retained artifacts
- Customer and sharing-enabled accounts kept separate
- Failure paths tested for secret absence
05Integrity
Security evidence must belong to the exact bytes under review.
A clean scan of yesterday's tree cannot approve today's candidate. Source inventories should hash actual bytes in deterministic order, declare their inclusion rules, and enforce a file-count floor so an empty or partial scan cannot pass silently. Build, dependency, secret, configuration, image, and policy verdicts should all bind to that identified subject.
Security is still not finished when automated gates pass. Independent review, production isolation validation, incident response, recovery drills, and customer-specific acceptance remain separate forms of authority. A trustworthy record says which of those happened and which remain open.
- Exact source inventory and digest
- Independent scanners that can fail
- Append-only verdict artifacts
- Explicit limitations and open human gates
Design partners
Security should constrain the agent before the agent can surprise you.
Constrain the agent first, then check the pull request it opens. TraceAxiom Verify is a GitHub Action, in development and not installable yet, that runs a pull request’s tests on base and head, checks its claims, and posts one verdict with its reasons.
Join the waitlist