TL;DR: A coding agent inherits a developer's standing privilege and uses it at machine speed, without the developer's judgment about which parts to use. That is an authority-design problem, not a monitoring problem. The architectural answer is to scope authority to the operation rather than to the identity, and the practical answer starts with deciding who owns the risk, because most enterprises have not.
Enterprise coding agent security is usually approached as a tooling question: which agent, which settings, which monitoring. Those matter and they are downstream of two decisions most organizations have not made explicitly.
The first is ownership. The second is what authority an agent should hold, which is a different question from what a developer holds. This page is about both, and about how to evaluate the products that claim to answer them.
Table of Contents
- What Is Enterprise Coding Agent Security?
- Who Owns Agent Risk
- Agent Identity Is Not Service Identity
- The Problem With Standing Privilege
- Operation-Scoped Authority
- What Evidence to Require
- Vendor Evaluation Criteria
- Architecture Decisions, in Order
- Frequently Asked Questions
What Is Enterprise Coding Agent Security?
Enterprise coding agent security is the practice of governing what autonomous coding tools may do inside an organization's systems: which authority they hold, what evidence exists of their actions, and who is accountable when something goes wrong.
Three things change relative to securing developers, and only the third is genuinely new.
Speed. An agent executes a sequence in seconds that a developer would take an afternoon over. Controls built around human-paced review, including approval prompts, degrade under that rate. This is a quantitative change with qualitative consequences: approval fatigue is not carelessness, it is a rational response to a prompt rate no one can sustain.
Breadth. A developer working on a bug touches the files relevant to it. An agent given the same task may read the whole repository first, because that is a reasonable strategy. Gensee's AP-003 repository recon pattern describes this directly: agents build a mental model from source, tests, manifests, CI, deployment, infrastructure and secret references before later actions. Nothing about it is malicious, and it changes the exposure profile of every credential in reach.
Composition. The genuinely new property. Individually legitimate actions compose into a capability nobody granted. Gensee's AP-006 capability composition analysis names it: files, shell commands, tools, memory, credentials and network actions combine into a workflow-level capability that was never explicitly authorized. Every control that evaluates one action at a time is structurally unable to see this, which covers essentially all of them.
Who Owns Agent Risk
This is the question that determines whether anything else gets done, and it is genuinely contested rather than obvious.
The candidates each have a real claim and a real gap:
- Security owns threat modeling and incident response, and typically lacks the context to say which agent actions are normal for a given codebase.
- Platform engineering owns the machines, the CI and the deployment path, and is usually measured on developer velocity, which makes them a poor choice for a control that adds friction.
- Engineering leadership owns the tooling decision and the budget, and is rarely equipped to specify controls.
- Individual teams own the day-to-day context and cannot set enterprise policy.
The arrangement that works in practice splits it: security owns the policy and the evidence requirements, platform owns the enforcement mechanism, and engineering leadership owns the exception process. The failure mode to avoid is the common one where security owns the policy but not the mechanism, and discovers the policy was never enforced.
Two concrete things make ownership real rather than nominal. Someone must be named for the exception process, because exceptions are where policy erodes and an unowned exception queue becomes permanent. And someone must be accountable for whether the controls are actually running, which is not the same as whether they were configured: Claude Code's sandbox fails open unless sandbox.failIfUnavailable is set, and Cursor's Linux sandbox does not run at all below kernel 6.2 with Landlock v3. A policy that assumes both are active, with nobody verifying, is a document rather than a control.
Agent Identity Is Not Service Identity
Most enterprises reach for their existing service identity model and find it does not fit. It is worth understanding why before designing around it.
A service identity is stable, scoped to a known function, and used in predictable ways. A CI runner's token does the same class of thing every time it runs, which makes least privilege tractable: you enumerate what it needs and grant that.
An agent identity is none of those things. Its function is whatever it was asked to do this session. Its access pattern varies by task. Enumerating what it needs in advance means enumerating what any developer might ask, which is the whole permission set. That is why standing least-privilege grants tend to converge on the developer's own permissions, at which point the exercise has not accomplished anything.
Three properties an agent identity needs that a service identity does not:
- Attribution to a human. Every agent action traces to a person who initiated it. Not the team, the person.
- Session scope. Authority granted for one task does not persist into unrelated later ones, which is where the failures Gensee documents in multi-session agent safety accumulate. Native controls do not currently do this: Claude Code's "Yes, and don't ask again" writes a persistent allow rule to local settings, so an approval granted during one debugging session applies indefinitely.
- Operation scope. Authority that is narrower than the session, sized to the specific operation rather than the identity holding it.
The third is the architecturally interesting one and the subject of the next two sections.
The Problem With Standing Privilege
An agent running on a developer's laptop holds that developer's standing privilege: their SSH keys, cloud credentials, kubeconfig, package registry tokens, and whatever their shell exports. This is not a misconfiguration, it is how running a process as a user works.
What makes it a problem specific to agents is that the developer's judgment about which parts of that privilege to use is no longer in the loop for each action. A human with production credentials uses them a few times a year and thinks about it each time. An agent with the same credentials in its environment may use them because a plausible debugging path led there.
Gensee's AP-004 credential harvesting pattern documents the route precisely: legitimate debugging, deployment, CI and infrastructure tasks lead agents toward secrets, tokens, kubeconfigs, environment variables and authenticated CLI state, with no step looking wrong on its own.
The defaults compound it. Claude Code's sandbox grants read access to the entire computer by default, with documentation noting this still allows reading ~/.aws/credentials and ~/.ssh/, and stating that there is no built-in credential deny list. Nothing is protected until an administrator names it.
There is one pattern in the vendor landscape that addresses this structurally rather than by policy, and it is worth studying because it points at the right shape: Codex's cloud environments make secrets available only during the setup phase and remove them before the agent phase starts. A credential that is not present cannot be misused. That is a categorically stronger guarantee than a credential that is present and guarded.
Operation-Scoped Authority
Generalizing that pattern is the architectural move: stop asking what authority the agent should hold and start asking what authority this operation requires.
Gensee's work on the shift from ambient privilege to operation-scoped authority sets this out concretely. A single request resolves to one of five execution paths rather than inheriting a standing grant:
| Path | What it does |
|---|---|
| Existing environment | Run in place, unchanged, where the operation warrants no more |
| Trusted mediator | Perform the effect without transferring the secret to the agent |
| Fresh capability cell | Make risky work disposable |
| Live TClone fork | Preserve state without laundering authority |
| Deny or require approval | Refuse, or escalate to a human |
Two supporting concepts carry most of the practical weight. In-place leases add only the missing authority for a specific operation rather than granting a durable role. And the promotion boundary governs what crosses back out of an isolated execution into the real environment, which is the point at which an effect becomes durable and therefore the right place to make a decision about it.
The reason this framing matters for an enterprise architecture decision, rather than as vendor vocabulary: it changes the unit of authority from the identity to the operation, which is the only change that makes least privilege tractable for a workload whose function varies by request. The broader system this sits inside is described in Gensee's operation security layer work, which organizes it into five planes covering admission and policy, execution and isolation, authority and effects, observation and evidence, and persistence and recovery.
What Evidence to Require
Set the evidence requirement before selecting a tool, because it is the requirement most likely to be quietly unmet.
Five things a record must contain to answer the questions that actually get asked:
| Requirement | Question it answers |
|---|---|
| Actor | Which agent, which session, which human, on whose behalf |
| Authority | Under what grant, made when, by whom, in which session |
| Action | What was attempted, with arguments |
| Effect | What durably changed, identified so it survives the session |
| Provenance | Where this record came from, and whether the observed process could have altered it |
The last row is the one that separates categories. Native agent telemetry, including Claude Code's OpenTelemetry export, Codex's opt-in OTel and Cursor's enterprise compliance logging, all describe the agent's own view of its actions. That is useful and it is not independent evidence.
Gensee's trace analysis of eight autonomous agent runs shows why the distinction has operational consequences rather than only philosophical ones: what exposed two boundary crossings was service semantics, independent evidence and persistence, none of which activity volume captured. An evidence requirement written as "we log agent activity" will be met by tooling that cannot answer the question you will eventually ask.
Vendor Evaluation Criteria
Eight criteria, weighted for an enterprise buyer rather than an individual developer:
- Unit of authority. Identity-scoped or operation-scoped. This is the architectural question and most products answer the first.
- Evidence provenance. Produced by the agent or beside it.
- Cross-session lineage. Whether anything connects an action today to one last week. If nothing does, the product is session-scoped whatever its category label.
- Policy distribution and precedence. Can a developer weaken it locally. Cursor's team Auto-review configuration overriding local files entirely is the pattern to look for; a merge is weaker.
- Failure behavior. Fail open or fail closed, and whether that is configurable per phase.
- Coverage limits, stated. A vendor without a ready gap list has not thought about it.
- Platform reality. Requirements that silently disable the control. Cursor's kernel 6.2 and Landlock v3 requirement, Claude Code's lack of native Windows sandbox support, Codex's behavior under Docker.
- Fleet coverage. Whether one deployment covers agents from multiple vendors, or you are buying per product.
Gensee's 15 questions to answer before deploying AI coding agents is the operational companion to this list, covering readiness rather than vendor selection.
Architecture Decisions, in Order
Seven decisions, sequenced so each has the input it needs:
- Name the owners. Policy, mechanism, exceptions. Three names, written down.
- Decide the evidence requirement, including the provenance row, before evaluating tools.
- Inventory standing privilege on developer machines. What an agent inherits today is what it can use today.
- Set the credential floor centrally. Nothing is denied until named; distribute the list through managed settings rather than asking developers to configure it.
- Verify the controls run. Kernel versions, sandbox availability, fail-open settings. Configuration is not operation.
- Choose the unit of authority. Standing grants scoped to identity, or authority scoped to the operation. This is the decision the rest of the architecture follows from.
- Start observing before enforcing. The evidence for which class of effect to block does not exist until you have run a real workload.
Frequently Asked Questions
Who should own AI coding agent risk in an enterprise?
Split it: security owns the policy and evidence requirements, platform engineering owns the enforcement mechanism, and engineering leadership owns the exception process. The common failure is security owning a policy without owning the mechanism, and finding later that it was never enforced.
Why doesn't least privilege work for coding agents?
Least privilege requires enumerating what an identity needs in advance. An agent's function is whatever it was asked to do this session, so enumerating in advance means enumerating everything any developer might ask, which converges on the developer's full permission set. Scoping authority to the operation rather than the identity is what makes the exercise tractable.
What is operation-scoped authority?
Authority sized to a specific operation rather than held standing by an identity. In Gensee's model a request resolves to one of five execution paths, including a trusted mediator that performs an effect without transferring the secret and a fresh capability cell that makes risky work disposable, with a promotion boundary governing what crosses back out.
Is agent telemetry enough for an audit?
It depends what is asked. Native telemetry from Claude Code, Codex and Cursor records the agent's own account of its actions, which answers "what did the tool report." It does not answer "how do you know," because the record comes from the observed process. Set the provenance requirement explicitly.
What is the first thing to fix?
The credential floor. Claude Code's documentation states there is no built-in credential deny list, so nothing is protected until named, and its sandbox defaults to reading the whole machine. Distributing that list through managed settings is a small change that closes the widest default gap.
Conclusion
The tooling questions are real and they are downstream. Decide who owns the risk, decide what evidence you require including its provenance, and decide whether authority is scoped to identities or to operations. Those three answers determine which products can actually meet your requirements, and most evaluations run in the opposite order.
Gensee Crate is built around operation-scoped authority and independent evidence, and Gensee's published architecture and trace research sets out the reasoning in full. To discuss how it applies to your environment, book a demo, see pricing, or read the research on the Gensee blog.