Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Which SOC 2 Controls Apply to Coding Agents That Hold Credentials?

A coding agent that holds a credential is tested against the same trust services criteria as any service account, and the weight falls on logical access, change management and monitoring. Ask what the credential can reach, who approved the change it made, and what record shows what its model was shown.

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

A team preparing for an audit may assume coding agents need a framework that does not exist yet, and they do not. A coding agent that reads a credential and changes code is a principal with access, and the criteria already ask whether access is granted, limited, reviewed, removed and logged, and whether a change is authorized before it takes effect. What is new is the shape of the principal: an agent whose credential lets it read a value it may not need to read, and whose model has already seen every field on the screens it worked through. This page builds the mapping the title asks for. It names the categories the criteria cover, then takes three control areas in turn, logical access, change management and monitoring, and asks what each one requires when the account is an agent and the asset is a credential. The worked example is a single control mapping table for a coding agent that holds a deployment credential, with the evidence each row needs. It reads the standards and vendor documentation that bear on the question, and the last section states the control class that fills the row the mapping leaves empty.

Key findings

  • 1Password's blog for its OpenShell integration states that "the agent sees placeholders rather than real credentials" inside the sandbox, a design for the agent's own API calls that the page does not describe as independently tested (1Password, 2026).
  • Veracode's test of AI-generated code found that models "make the wrong choices nearly half the time" and put Java's security failure rate "over 70 percent," which is why a change an agent makes needs review before it merges (Veracode, 2025).
  • A governed environment replaces a credential with a consistent token before any model reads the screen, so the agent works with a name such as DEPLOY_KEY_001 and never holds the string (What Is an AI Control Record?).
  • Real values resolve only at the approved destination at the moment of an approved action, the one point in a run where a credential becomes usable (What Is Supervised Delegation?).
  • The 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 that system is inside the evaluation (AICPA & CIMA, 2017).
  • The mapping for agents in general is already published, and credential custody adds one distinction: who can use the credential is a question the criteria ask, and what the model was shown is not (Which SOC 2 Controls Apply to AI Agents?).

Which SOC 2 criteria does a coding agent with a credential fall under?

SOC 2 has no agent section. The Trust Services Criteria are control objectives grouped under security, availability, processing integrity, confidentiality and privacy, and an auditor tests whether a system's controls meet the objectives the organization claims for it. An agent that reads a credential and changes code is a principal inside that system: the account it uses, the repository it writes to and the data it reads are all system behavior.

The pressure to answer that question is recent. One 2026 survey found 62% of organizations experimenting with AI agents and 23% scaling them anywhere, as How to Use AI Agents for Google Cloud Deployment reports.

This page covers the case where the agent works through a browser on rendered pages: a cloud console, a dashboard, a repository settings page, a sign-up form. A governed browser environment covers what the agent reads and does on those pages, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP.

The record for this page is one control mapping table for a coding agent that holds a deployment credential of the kind pasted into a CI settings page. Each row is a control area an auditor samples and what custody of the credential supplies or leaves missing.

Control area What the criteria ask What the agent's custody supplies What a buyer should verify
Logical access Who may reach the system, at what scope, and when access is removed A credential the agent presents, sometimes shared across runs Whether each run has its own identity and a dated removal
Change management That changes are authorized, reviewed and tested before they take effect An agent that can edit code, CI configuration and repository settings Which changes needed a named approval, and what the approval covered
Monitoring That activity is logged, reviewed and acted on Action logs, where the vendor provides them Whether the log records the action, the credential and what the model was shown
Confidentiality That data is protected from disclosure Nothing about what the model reads on a page What the model received when the page rendered

What does logical access require when an agent holds the credential?

Logical access asks three things of any principal: what it may reach, at what scope, and for how long. For a coding agent the credential is the access, so those become questions about the credential: which runs share it, what it reaches beyond the task, and when it stops working.

Teleport's documentation states that agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key," and the same page marks most of its listed capabilities in progress or not started (Teleport, 2026).

Browserbase's guidance is to store "cookies, session tokens, and local storage" to prevent repeated logins, and its page states: "Log in once, then reuse the saved authentication state" (Browserbase, 2026). A saved session is a durable access path, and the page does not explain how usernames and passwords are stored in automated sessions.

The principle under both is the one NIST states for zero trust: no implicit trust in an asset or account "based solely on their physical or network location" (NIST, SP, 2020). CyberArk describes its approach the same way, as privilege control over the identity rather than the model's view (RedactSure vs CyberArk: 2026 Comparison & Alternative).

What do the vendors themselves say?

Three vendor pages bear on the mapping, and each documents a control that fills part of a row. None documents an approval that names a person.

1Password's blog states that "the agent can work with real systems without holding any credentials in its context," that the gateway "replaces a placeholder with the real value only when the agent sends a request to an approved host," and that it "stores them by reference rather than by value" (1Password, 2026). That puts the decision to release a value outside the agent and ties it to a host, the closest of the three designs to a per-request access decision. The page does not describe independent testing or audit of the integration.

Browserbase's page advises that "for an authentication flow requiring some level of security, try to create an app password," which is the vendor saying a saved session is a weak credential for a sensitive flow (Browserbase, 2026).

Teleport's page lists "comprehensive audit trails and behavior analysis for agent actions across infrastructure" among its capabilities, and marks most of the items in that list in progress or not started, so the trail is a stated aim rather than a shipped control (Teleport, 2026).

Read together, the three describe where a credential is kept and, in one case, when it is released, and none names the person who approved the run.

How does change management apply to code an agent changes?

Change management asks that a change is authorized, reviewed and tested before it takes effect, and that the record shows who approved it. An agent with a repository credential can open a pull request, edit a CI configuration or push to a protected branch, so each act is a change the criteria cover.

SLSA's threat list includes an attacker who "compromised the build platform and installed an implant that injected malicious behavior during each build" and one who "added an innocuous dependency and then later updated the dependency to add malicious behavior" (SLSA, 2026). Both changes survive a reviewer who reads a diff, and neither is described with an approval step.

Willison's design patterns take the structural route: they "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," and one pattern lets an agent trigger tools while it "cannot be exposed to or act on the responses from those tools" (Willison, 2025). The post offers no empirical test, so it is an argument about structure.

The steps that cannot be undone are the ones a change control gates. On a GPU instance launch, five of the steps commit the account to something you cannot take back, and those five stop (How to Use AI Agents to Launch an EC2 GPU Instance). A credential in the agent's environment does not stop them.

What does monitoring require when an agent acts with a credential?

Monitoring asks whether activity is logged, reviewed and acted on. For an agent, the log has to answer a question an ordinary access log does not: which actions were the agent's, and which credential carried them.

The risk the log exists to catch is the one OWASP names as excessive agency: "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," with excessive permissions among its listed root causes (OWASP, 2025). That root cause is testable in a review, and the question is concrete: what could this credential do that the task did not need?

NIST's adversarial machine learning report "identifies current challenges in the life cycle of AI systems" and offers its taxonomy as terminology "meant to inform other standards and future practice guides" (NIST, Adversarial, 2025). The criteria do not name prompt injection or an agent's autonomy, so the organization decides how its controls cover both and an assessor tests the decision it wrote down.

A complete action log still leaves one column of the table empty. The log records what the agent did with the credential, and it does not record what the screen showed the model. The vendor pages offer the log and not the view.

Does any criterion cover what the model was shown?

Confidentiality asks that data is protected from disclosure. The disclosure a coding agent makes is unusual: nothing has to leave the system for a value to be in the wrong place, because a value rendered on a page is in the model's context as soon as the agent reads it, and the context travels with every request for the rest of the run.

The nearest documented design in this review is 1Password's sandbox, where the agent holds placeholders "including a placeholder for its model key" (1Password, 2026). It covers credentials and does not cover the customer records a settings page or a dashboard renders, so it is a relative of the control this row needs and not an answer to it.

The other nearby category governs a person's data movement in a web application, which is a different question from what a model reading that page receives (Enterprise Browser or Render-Layer Tokenization?).

So the evidence the confidentiality row needs is a statement of what the model was shown, produced at the point the page was rendered. An access review does not produce it, an action log does not produce it, and a screenshot taken after the run shows the page rather than the context. Until a team can produce that statement, the row stays open and the mapping is a list of the controls that exist beside the gap rather than a set that closes it.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on names such as DEPLOY_KEY_001. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

Against the table above, the class changes the evidence rather than the criterion. Logical access becomes a per-run question, because the token belongs to one run and stops with it. Change management gets a point of approval before the change, since the action that would carry the change waits on a named person. Monitoring gets a record that includes the screen as the model saw it alongside the action that followed. Confidentiality is the row it changes most: the value never enters the context, so what a model could disclose is a token.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a credential exported to a shell, or pasted into a file the agent reads, stays a matter for the sandbox and the credential store the team configures.

What it does not change is the criteria themselves. The mapping still has five rows, the auditor still samples the same evidence, and one row becomes producible.

Methodology and limitations

This page rests on the Trust Services Criteria as published by the AICPA and CIMA, on OWASP's LLM06 entry, on NIST's adversarial machine learning report and its zero trust architecture, on the SLSA specification, on vendor documentation from 1Password, Browserbase and Teleport, on Veracode's press release, and on Willison's practitioner analysis, together with the existing RedactSure research pages linked above. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted phrases are cited to the page that states them, and the criteria categories are reported as the AICPA and CIMA document them.

RedactSure did not test any named product hands-on. Where this page says a vendor's page does not describe something, that means the recorded facts for that page do not include it, and the statement is not a claim about what the product does. Vendor features change, and the page carries its date, so a reader should treat a release after that date as unreviewed until the test at the end is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers; the worked example describes a record type, a control mapping table for a coding agent that holds a deployment credential, and not an organization.

Determinations about whether a control mapping meets the criteria, and whether the evidence behind a row is sufficient for an assessor, belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own credential, kept beside the record the run produces.

What the record shows

Read together, the record answers the title with three control areas and one gap. A coding agent that holds a credential falls inside logical access, change management and monitoring as any service account does, and the vendor documentation reviewed here supports the access row: a cryptographic identity in place of a shared key, a saved session in place of a repeated login, a value released only to an approved host. What none of it supports is a statement of what the model received on the pages it read, which leaves the organization to decide how confidentiality covers a value that reached a model without leaving the system. RedactSure's design puts that evidence at the render layer. For one agent and one credential, a team should establish which run held it, who approved the change it made, and what the model saw when the credential was on screen; writing those answers into the table is a quick test of which row still has no evidence beside it.

Frequently asked questions

Which SOC 2 controls apply to coding agents that hold credentials?

There is no agent-specific criterion. A credential-holding agent is tested where any service account is tested: logical access, for who can use the credential and when it is removed; change management, for the code and configuration it changes; and monitoring, for the record of what it did. Confidentiality applies to what it can read. The mapping is the organization's to write, and the criteria ask it to show the evidence behind each row, not a tool name.

Does a coding agent need its own identity in the access review?

It needs an identity the review can name. A shared key, or a person's login, puts the agent's actions under someone else's name, and the review then certifies a person for work a program did. Teleport's documentation argues for a cryptographic identity per workload instead of a shared API key, though its page marks most of that framework in progress. Until that identity exists, the review cannot say who held the credential on a given day, and it cannot date the removal.

What evidence does an auditor sample for a change the agent made?

The same evidence a change control produces for a person: the change, the review that preceded it, the test that passed and the approval. The complication is that the agent may have opened the pull request, edited the pipeline file and pushed the tag itself. A log shows those acts and does not show authorization, so the approval has to come from outside the agent's own process. SLSA's threat list is why the review covers the build as well as the diff.

Is a saved browser session the same as a credential?

It is a credential with a longer life and a less clear owner. Browserbase's guidance to store cookies, session tokens and local storage is a recommendation to reuse a login, and a reused login is access that nobody re-provisions and nobody remembers to revoke. The same page advises an app password for flows that need more security, which is an acknowledgement of the limit. For an access review, the questions are when the session expires and who can end it, and neither answer is usually written down.

Can a SOC 2 report cover what the model saw?

Not by naming it. The criteria cover controls over the system, and what a model was shown is a fact about the system's behavior, so an organization can write a control for it and have that control tested. No page reviewed here describes one, and no vendor page describes a record of it. A team that wants the row filled has to build the control and keep the evidence.

What should a team put in the mapping table first?

The credential and its lifetime, because that row decides the others. Name each agent, the credential it holds, what the credential can reach and who removes it when the task ends. Then add the change it can make, the approval that precedes that change and the log that follows it. The last row, what the model was shown, is the one most tables leave blank; leaving it blank is honest, and it is the row a reader should notice.

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 Keeps a Credential-Holding Coding Agent Inside the Criteria

The criteria were written for accounts, and they never ask what the model received when a page rendered, evidence that only a control at the page produces.

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

Before: the agent opens the repository's deploy key settings page and the key renders in full. Inside the governed environment: the page renders DEPLOY_KEY_001, the model composes the change with the token, and a named approver sees the pending key before the real key is placed.

RedactSure is deploying now with enterprise and government customers. Veracode's test found models making the wrong choices nearly half the time.

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

See it on your own workflow

Your auditor will test the controls against what the agent actually did. Bring a deploy key task and see, with test values, what the approver reviews before the real key is placed. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.