A coding agent working in PocketOS’s staging environment hit a credential error, found an unrelated API token and used it to delete the production database and the backups stored alongside it.
Nobody attacked anything, and according to the founder, all it took was nine seconds.
Most of the conversation about coding agents is about the code they write, but engineering and security leaders need to be able to say what an agent can set in motion, and whose authority it uses when it does.
Enforcement is thinnest where AI agents do their work
In Delinea’s 2026 Identity Security Report, Fall Edition, 2,254 IT and security leaders told us where AI access is checked at the moment of action, before the action runs. CI/CD pipelines came in at 35% and Kubernetes at 28%, the lowest of the six environments we asked about. And 47% of organizations lack enforcement at the moment of action across at least two of the six.
Those are the environments developers hand off to agents first, and they're where deploy roles, cluster permissions, and production credentials live.
The agent doesn’t need the prod credential
Say you ask an agent to bump a service in staging. It updates the deploy workflow and opens a pull request. On GitHub, a pull request from a branch in the same repo runs the workflow as modified in that PR. If the workflow can pick up the pipeline’s cloud role, and that role reaches prod as well as staging, the agent’s edit now has production authority behind it.
The agent never touched a prod credential. It borrowed the pipeline’s.
Over-scoped CI roles were a problem long before agents showed up. Workflows branch too, but someone wrote and reviewed every branch. An agent can write a new one and trigger it in the same session.
Permissions that were safe for a predictable job become much broader once the identity using them can improvise
Identity has to follow the action
Security teams already know how to limit privileged access. Agents need those same controls applied to each action because they decide what to do next on their own.
Scope the agent to the task, not the person who launched it. You might be allowed to query the production database, but your agent shouldn’t inherit that because you started it. A policy that can tell the two apart lets your query through and stops the same query when the agent sends it.
Treat the pipeline as a privileged identity. The deploy role is what actually touches prod, so it deserves the scrutiny you’d give an admin account: one role per environment, and a human review before anything reaches production.
Keep enforcing policy after access is granted. Authentication only checks who's connecting, so a command an agent runs 40 minutes into the session goes through unchecked. Access should exist only while the task needs it, and each consequential action should be checked against policy before it runs.
Where Delinea fits
Delinea extends Privileged Access Management from the point of access to the moment of action. For the connections it brokers, including databases, servers, Kubernetes and MCP tools, access is granted just-in-time for the task, and in a brokered session the credential is injected at the proxy so it never reaches the agent. Each query, command and tool call is checked at runtime, and one that’s out of scope doesn’t run.
Start with one agent-assisted workflow
Pick one agent-assisted workflow and trace it to production. List each identity it touches, from the agent to the runner to the deploy role to the cluster, and what each one is allowed to do. Then find the point where a production action from a staging task would be stopped. If the answer is “we’d catch it in the logs,” you’ve found your gap.
Explore the findings in Delinea’s 2026 Identity Security Report, Fall Edition: The AI Enforcement Gap.
WHITEPAPER
The AI Enforcement Gap
