Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Do Coding Agents Break Separation of Duties?

Yes, when a single grant lets one agent write a change, approve it and deploy it, because every step runs as the same principal with the same credential. Keep the approver a named person outside the agent and the deploy credential outside the agent's process, then check what the model was shown at each step.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Enterprises that let a coding agent write and deploy code put their oldest change control at stake. Separation of duties is the oldest control in change management: the person who writes a change is not the one who approves it, and the person who approves it does not hold the key that deploys it. A coding agent collapses those roles into one process, because the session that edits the repository can open the pull request, and the credential in its environment can merge and deploy. The duties have not disappeared; they have narrowed into a single principal, and what goes missing is the evidence that the four duties were performed by more than one party, which is the thing an auditor tests. This means the question for an enterprise is whether any step in the loop requires a second party, and the person who answers for the loop is usually the developer who started the agent. A reviewer deciding whether to approve the agent needs a narrower answer than a product comparison: which of the four duties the grant carries, and which one needs a person. The record followed here is one agent that writes and deploys under one grant, and the finding is that vendor designs narrow its credential while only a separate approval restores the second party.

Key findings

  • OWASP's entry for excessive agency describes the risk as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, 2025).
  • As summarized by Debevoise & Plimpton, FINRA's 2026 oversight report flags that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2026).
  • Datadog reports of its own customer base that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions" (Datadog, 2025).
  • AWS documents that "the resulting session's permissions are the intersection of the role's identity-based policy and the session policies," so a session can be narrower than its role and still one principal (AWS, 2026).
  • A render-layer control replaces a value with a consistent token before any model reads the page, so an agent working a repository settings page holds DEPLOY_001 where the deploy key sits and the key never enters the model's context (Enterprise Browser or Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment an approved action runs, so the credential reaches the pipeline a named person approved and not the model that proposed the deploy (What Is Supervised Delegation?).

What does separation of duties cover when a coding agent acts?

Separation of duties assumes a change passes through four hands: someone writes it, reviews it, approves it and deploys it. The control is that no one person holds two of the last three. A coding agent does not change that list; it changes who holds the entries, because authority sits in the grant, not in the employee record beside it. A grant that permits repository writes, merges and deploy triggers gives one principal three of the four, and the credential in the environment supplies the fourth.

Scope matters before the duties do. A governed browser environment covers what an agent reads and does on a rendered page: a repository settings page, a pipeline settings page, a cloud console, an approval screen. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A coding agent spends much of its day in those places, in git commands and in a CI runner, so a browser control governs the screens where the grant is configured and an approval is given, not the shell where the merge runs.

The accountable person is the developer. The page records that most enterprise agent deployments cannot name the person accountable for a given agent action, and that this absence becomes the first audit finding after an incident (What Is Supervised Delegation?). The developer who started the agent supplied the grant and answers for the deploy.

One rule written for people applies with more force to an agent: as summarized on Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?, Google's guidance is that the super admin account should be used only when needed.

What can one agent do under a single deploy grant?

The record type is an agent that writes and deploys under one grant, the arrangement a Google Cloud deployment walkthrough covers (How to Use AI Agents for Google Cloud Deployment). Its session opens the pipeline settings page of a cloud console where the deploy key is displayed, reads what the page renders, edits a workflow file, opens a pull request, merges it and triggers the deploy. No step in that sequence requires a second person, and no step requires a different credential.

AWS documents the reach of a credential like it. Its duration "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," and role chaining limits a session "to a maximum of one hour" (AWS, 2026). A session policy can narrow the role for the task, which is real least privilege. Neither adds an approver.

A secret manager can keep the value out of the repository. Doppler's page for coding agents offers to "give every coding agent its own scoped, read-only, expiring set of credentials," with values "injected at runtime instead of written to a .env, so agents can't read, log, or commit them" (Doppler, 2026). Read-only and expiring are the right limits on what one credential reaches, and the page does not say whether the agent can read the variables injected into its own process.

Masking is the other control teams reach for. GitLab states that "masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). A masked variable governs what the log records, not which principal may trigger the job.

What do the vendors themselves say?

Arcade frames the authorization question for an agent as "Can this agent, acting for this user, perform this action on this resource?", and argues that "even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed" (Arcade, 2025), a rule about the scope of one action that leaves the approver outside it.

Infisical's Agent Vault starts from the same premise, that "the agent should not be trusted with direct access to any secrets," and it terminates TLS so the proxy sees the request rather than forwarding an opaque tunnel (Infisical, 2026), which keeps a value out of the agent's reach and does not claim to stop exfiltration or to add a person to the loop.

Composio's connected accounts keep credentials away from the model: "Credentials never pass through your app or the model, so it's safe to surface the link right in the chat," and "the user signs in on the hosted link and Composio stores the resulting connected account" (Composio, 2026), an account that acts for the user without describing encryption, physical storage or an approver.

Vendor, per its documentation What the page documents What it leaves open
Arcade "Can this agent, acting for this user, perform this action on this resource?", and read-only access unless a write is explicitly needed Who approves an action the scope permits
Composio A hosted sign-in that stores a connected account, with credentials kept away from the app and the model What the model receives on the page the account acts on; storage and encryption sit on another page
Infisical "The agent should not be trusted with direct access to any secrets"; Agent Vault terminates TLS at the proxy An approver, and any claim to prevent exfiltration
Doppler Scoped, read-only, expiring credentials per agent, injected at runtime rather than committed Whether the agent can read the variables in its own process
AWS STS A session whose permissions are the intersection of role and session policies, 15 minutes to the role maximum Who requested the session; the call carries no approval

Read together, the designs do one thing well and stop at the same line. Each narrows what a credential can reach and shortens how long it can reach it. Whether a person must agree before the action runs is not described in the pages reviewed, and that is the question a separation-of-duties review has to put to the vendor in writing.

What do the standards and the regulator say about one agent holding every duty?

OWASP's entry names excessive functionality, excessive permissions and excessive autonomy as the root causes of excessive agency, which is what a single write-and-deploy grant supplies at once (OWASP, 2025). The entry treats those as causes rather than as the risk itself, and the risk is a damaging action taken on a manipulated output.

As summarized by Debevoise & Plimpton, the same report warns that agent chains "may be difficult to reconstruct, complicating auditability" (Debevoise & Plimpton, 2026). Reconstructing a deploy means answering two questions: which credential ran, and who agreed. A pipeline log answers the first. It rarely answers the second, because the agreement was a step in a model's reasoning and not a record that another person signed.

The audit standard most enterprises already run against does not exempt the agent. As summarized on Which SOC 2 Controls Apply to AI Agents?, the AICPA's Trust Services Criteria are used "to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy" of a system, and an agent operating inside the system falls inside the controls evaluated. A control that asks for a second person's approval is tested at the agent's action, not only at the employee's desk.

The conclusion the standards support is narrow. None of them prescribes an architecture, and none names a product. Each asks for evidence that a second party stood between the change and the deploy. A passing test that a model generates is not that party, and neither is a written policy.

What happens when the agent approves its own work?

The failure is structural before it is adversarial. If the agent opens the pull request, reads the test result and merges, the review comes from the same model that wrote the change, and the merge is authorized by the credential that wrote it. A test suite is evidence about the code. It is not evidence about who agreed to ship it, and a green check carries the same authority whether a person or a model caused it.

The adversarial version is worse, because the model's agreement can be arranged. An environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information, as summarized on Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?. An agent that reads a pipeline page, an issue comment or a release note is reading content another party can write.

Once a value is in the model's context it can come back out. Carlini and colleagues extracted training data from a large language model verbatim, as summarized on How to Use AI Agents to Deploy Azure GPU Virtual Machines, and a deploy key the model read on a settings page sits in the same position.

What separates the two failures is the record. Neither a system of record nor a log answers both questions an incident raises: what did the model see, and who answered for what it did (What Is an AI Control Record?). Until both answers exist for a given deploy, self-approval is not a policy choice. It is an absence.

What does a governed environment change?

The control class that answers this page is narrow and specific. Values on a rendered page are replaced with consistent tokens before any model reads the screen, so a model that proposes a deploy works with DEPLOY_001 and ENV_002 and never with the key itself. Real values resolve only at the approved destination at the moment an approved action runs: the pipeline receives the key, the model does not. A named person confirms the tokenization policy before a run and approves each consequential action inside it, including a merge, a settings change and a deploy. Every screen the model saw as tokens, every action it proposed and every approval with a name goes into one record the organization can export and read afterward.

That combination moves the separation-of-duties question from a property of the agent to a property of the run. The agent may still hold three duties in one process; the approval is no longer one of them, because the approval is a step a person performs outside the model, against a page the model cannot alter. The record supplies the evidence a control test asks for: which person approved, what the model was shown, and what the destination received.

The scope does not change. An environment of this kind covers the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP. On a coding task it governs the screen where the grant is configured, the page where a change is approved and the record of both, which is the part of the loop where a second person can actually stand, and it leaves the pipeline command and the edited file outside it.

Methodology and limitations

The page rests on five kinds of record. Vendor documentation supplies the documented behavior of six credential and pipeline designs: Composio's authentication page, Arcade's agent authorization post, Infisical's Agent Vault post, Doppler's coding-agent page, AWS's AssumeRole reference and GitLab's CI/CD variables page. A law firm summary of FINRA's 2026 regulatory oversight report supplies the regulator's wording. OWASP's LLM06:2025 entry supplies the standards position. Datadog's State of DevSecOps 2025 supplies the one measured figure. RedactSure's own pages on supervised delegation, the AI control record, SOC 2 scope and render-layer tokenization supply the description of the control class. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page.

RedactSure did not test any product hands-on. "Not described in the pages reviewed" means the cited pages do not state the behavior; it is not a finding that a vendor does not do it. Vendor features change and the page carries the date of the pages it read, so a reader should confirm a feature before relying on it. Statements about RedactSure's design describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an agent that writes and deploys under one grant, and not an organization.

Determinations about whether a given arrangement satisfies a separation-of-duties requirement belong to counsel, to the assessors who test the control and to the organization's own security and compliance officers. The page describes what the recorded documentation states and what the control class changes; it issues no opinion on any vendor's compliance.

What the record shows

The duties did not disappear when the work moved to an agent; they concentrated. A single grant that writes a change, opens the pull request, merges it and triggers the deploy gives one principal three of the four hands that separation of duties exists to keep apart, and the credential in its environment supplies the fourth. The documented designs narrow that credential well: shorter sessions, values injected at runtime, credentials the agent never holds. None of them adds the second party, and the regulator names the consequence, an action without human validation that is hard to reconstruct afterward. This means the answer turns on a separate approval, with the real value released only at the destination that approval names, and a better credential cannot supply it. Before approving an agent, a reviewer should run a short test on one agent and one task: name the person who approved the deploy and the credential the agent held, and compare both with what its model read on the page where the change was approved.

Frequently asked questions

Do coding agents break separation of duties?

Only when the grant puts every duty in one hand. An agent that edits a file holds one duty; an agent whose credential can also merge the change and trigger the deploy holds three, and nothing in that loop asks a second person to agree. The remedy is unchanged: the approval has to sit with a person the agent cannot act for, and the deploy credential has to sit where the agent's process cannot reach it. A narrower permission on the same identity does not change the duty.

Can an agent approve its own pull request?

It can where the repository lets the same identity that opened a pull request merge it, and many repositories do by default for an automation account. That is a configuration choice rather than a property of agents, and it is the first thing to check. A branch protection rule that requires a review from a different identity is the human-shaped version of the same rule, and it holds only if the agent cannot use that identity. Read the setting before the agent is connected, not after.

Does a short-lived, scoped credential restore separation of duties?

No. It reduces what a stolen or misdirected credential can reach and shortens the window, which is worth having. It does not create a second party. A session that expires in fifteen minutes still merges and deploys during those fifteen minutes with nobody else in the loop. Treat scope and expiry as limits on damage, and treat the approval as a separate control that a session policy cannot supply. The window matters, and it is not a person.

Can a second agent act as the approver?

Not as a separation control. A reviewer agent that runs on the same account, reads the same untrusted content and follows the same instructions is a second model, not a second party, and its approval is an event in the same context. It can check style or a known bad pattern. For the duty that matters, the approver has to be a person who can be named in a record and asked about the decision later. Two models on one account share one compromise.

What should an approval record show an auditor?

The person who approved, the action they approved, what the agent proposed before that approval, and what the destination received after it. A timestamp and a model name are not enough evidence, because neither answers what the model was shown. The record should also show the policy in force at the time, so a later change to the tokenization rules does not rewrite the history of an earlier deploy. Without that policy the record cannot be tested.

Is a masked pipeline variable enough?

No. Masking governs what a job log records, and GitLab states plainly that masking is not a guaranteed way to keep a value from a determined user. The job still holds the value, and the identity that can trigger the job still holds the deploy. Masking belongs in a set of limits that also includes scope, expiry and a named approval; on its own it changes the record rather than the authority. The duty follows the trigger, not the log line.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Separates the Approver From the Deploy Credential

Every design above narrows the credential and shortens its life, yet the agent still approves and deploys with no second party involved.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before, the model read the pipeline settings page with the deploy key in clear text and the trigger live, and its grant could push, merge and deploy alone. Inside the environment, the same page shows DEPLOY_001 and routes the trigger to an approval; a platform lead approves the deploy, and the key resolves at the pipeline.

RedactSure is deploying now with enterprise and government customers. 37 percent of the customers Datadog sampled still run IAM users in their GitHub Actions.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Separation of duties holds when the person who approves the deploy is not the agent holding the key. Bring a deploy your team delegates and see, with test values, who approves it and what the model reads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.