2026-08-07
An Agent Credential Is a Production Boundary
An agent with a goal and a reusable credential does not have autonomy. It has standing permission to turn one bad instruction into a production event.
Identity is part of the machine
Agent security is often described as an intelligence problem: make the model recognize malicious instructions, resist manipulation, and choose the safe action. That matters. It is also the wrong place to put the final boundary. A model interprets language. Authorization decides what a process can actually do after that interpretation goes wrong.
The credential attached to an agent determines its blast radius. A long-lived token that can read repositories, change infrastructure, open messages, and retrieve secrets collapses several business authorities into one bearer string. The prompt may describe a narrow task, but the system has granted a broad job. When those disagree, the credential is the truth.
Treat identity as factory machinery, not setup. Every run should receive an identity derived from the work it was approved to perform. That identity should expire with the run, expose only the required tools and resources, and leave a record that connects each action to the request that authorized it.
Every useful input crosses a trust boundary
An agent becomes valuable by reading things people did not write as instructions: issue descriptions, documents, web pages, logs, code comments, support messages, and tool output. The same context that makes the worker useful gives untrusted text a path into its decision loop. Telling the model to ignore hostile content is a filter. It is not containment.
The factory should label where information came from and keep that provenance through the run. External content can supply facts for analysis without gaining authority to change the plan. Tool output can describe a result without becoming a new policy. A retrieved document can inform a decision without selecting the next credential.
This separation must survive the conversation. If untrusted text can persuade the worker to request a more powerful tool, and the same worker can approve that request, the boundary is decorative. Expansion needs a different authority with a mechanical reason to grant it. Language may explain the need. Policy decides whether the need fits the approved task.
Grant capabilities per task, not per agent
A named agent role is not a permission model. Calling something a reviewer, researcher, or deployer does not constrain it if every role receives the same ambient credentials. The boundary has to exist in the systems being touched: repository scope, path scope, action scope, environment, spend, time, and consequence.
Start from the approved transition. A research run may read a bounded set of sources and write a structured artifact, but it cannot edit production code. A builder may modify named repository surfaces, but it cannot change the tests that define acceptance. A release worker may promote an already approved artifact, but it cannot manufacture a different artifact during deployment. Each identity exists to complete one transition and nothing beyond it.
Short lifetimes reduce the value of stolen credentials, but expiration alone is not enough. A powerful token that lasts five minutes can still do permanent damage in seconds. Combine time limits with narrow resource claims, explicit operations, budgets, network boundaries, and an exit condition that revokes authority when the intended result is produced or the run fails.
Approval must change the credential
Human approval is frequently implemented as a message: the agent asks, a person clicks yes, and the original process continues with the authority it already had. That creates an audit-shaped pause without proving what was approved. The action after the click may differ from the action shown before it, especially when the surrounding context keeps changing.
A real approval should mint a new, narrow capability bound to the reviewed action. It should name the target, operation, relevant artifact digest, environment, and expiry. If any of those change, the capability no longer fits and the factory must ask again. The approval becomes an enforceable object instead of another sentence in the transcript.
Reserve people for consequences that actually need judgment. Do not require a person to approve every harmless read and then train them to click through the dangerous write. Route low-consequence, reversible actions through policy. Escalate actions that cross a defined consequence boundary, and show the person the exact change the new credential will permit.
A hard boundary makes autonomy possible
Broad credentials feel fast because they remove design work from the first demo. They become slow in production. Every new integration expands the shared blast radius. Security teams compensate with reviews and manual approvals. Operators hesitate to let runs continue unattended. The supposed autonomous worker ends up surrounded by people because nobody can state what it is incapable of doing.
A governed identity system reverses that. The factory can run repeatable work without waiting for a person because the dangerous branches are mechanically unavailable. Logs become useful because actions map to task identities instead of a shared service account. Recovery becomes specific because the affected capability, artifact, and transition are visible.
Our position is that agents will replace people across repeatable delivery work, including coordination and routine security handling. That only happens at production scale when authorization is more reliable than human availability. The model will keep getting better at choosing actions. The winning factory will still assume it can choose wrong—and make the credential hold the line.
In response to Claude Mythos 5 made sock puppet accounts to socially engineer developers: here's what enterprises should know by VentureBeat.