How should security teams control AI agents that can read secrets and modify code?

They should control the action boundary, not just the credential boundary. An authorised agent may be allowed to inspect code or secrets, but it should not be free to externalise data, reset permissions, or delete critical files without additional checks. The right model combines least privilege, runtime inspection, and policy enforcement before execution.

Why This Matters for Security Teams

AI agents change the control problem because they do not follow fixed human workflows. Once an agent can read secrets and modify code, the real risk is not only credential theft but tool chaining, data exfiltration, permission changes, and destructive actions executed at machine speed. Traditional IAM assumes predictable roles and stable intent; autonomous systems can pivot across those assumptions in a single session. That is why current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework emphasises runtime controls, traceability, and bounded execution rather than static trust in the model or its credentials.

NHI Management Group has also shown how fast this surface expands in practice: The State of Secrets Sprawl 2026 reports that AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers. That matters because an agent that can read secrets does not need to steal them to create harm; it may simply copy, expose, or reuse them inside a code change, a ticket, or a prompt chain. In practice, many security teams encounter the failure only after an agent has already transformed a narrow permission into broader operational impact.

How It Works in Practice

The practical answer is to control the action boundary, not just the credential boundary. Security teams should issue narrowly scoped, short-lived access for each task, then evaluate every sensitive action at runtime before it executes. For agents, that usually means combining workload identity, policy-as-code, and just-in-time approval paths. The agent proves what it is through cryptographic workload identity, such as SPIFFE or OIDC-backed service identity, while policy decides whether the specific action is allowed in the current context.

This is where static RBAC starts to fail. A role like “code assistant” is too coarse when the same agent can read a secret, open a pull request, call an internal API, and reset permissions. The better model is intent-aware authorisation: allow the agent to inspect a repository, but require separate controls before it can export findings, modify auth configurations, or commit code that touches secrets. Runtime inspection should check the request, the target resource, the repo state, and the surrounding workflow. If the request is high risk, the system can force human approval or deny it outright.

• Use JIT credentials with the shortest viable TTL and automatic revocation on task completion.
• Separate read, write, and destructive actions into distinct policy paths.
• Log prompt, tool call, code diff, and secret access together for investigation.
• Prefer ephemeral tokens over long-lived static secrets wherever an agent can reach production systems.

For implementation guidance, the CSA MAESTRO agentic AI threat modeling framework and OWASP Non-Human Identity Top 10 both align with this approach: treat the agent as a high-velocity workload identity, not a user surrogate. These controls tend to break down when agents are embedded directly into CI/CD runners with broad repository and cloud permissions, because the toolchain itself becomes the lateral-movement path.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, so organisations have to balance speed against blast-radius reduction. That tradeoff is real in code-assist workflows, where developers expect fast feedback and low-friction commits. Best practice is evolving, but current guidance suggests that the highest-risk actions should be separated from ordinary editing. Reading secrets, generating patches, and proposing changes can be one workflow; merging, exporting, and permission changes should be another.

Edge cases usually appear in environments that blur human and machine authority. Shared service accounts, long-lived API keys, and broad CI runner permissions can make an agent indistinguishable from a privileged developer session. That defeats both incident attribution and containment. The Analysis of Claude Code Security is a useful reminder that even code-focused agents can leak or reproduce sensitive material unless the surrounding policy layer blocks unsafe externalisation. The same lesson appears in the Replit AI Tool Database Deletion case: code access alone is not the problem, unchecked execution authority is.

There is no universal standard for this yet, so teams should define risk tiers by action type, not by model brand or application label. That means separate guardrails for secret access, code modification, deployment, and permission management, with each one evaluated in context through frameworks such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams govern AI agents that can access enterprise systems?