Subscribe to the Non-Human & AI Identity Journal

How should security teams govern coding agents that already have access to production tools?

They should govern the agent as a delegated identity, not as a piece of software. That means scoping every token, browser session, and MCP connection to the task, requiring just-in-time grants for high-impact actions, and binding the agent’s rights to the human principal’s permissions. If the human cannot do the action, the agent should not inherit it.

Why This Matters for Security Teams

Coding agents are not just another SaaS integration. Once they can open terminals, call APIs, browse internal systems, or invoke MCP tools, they operate as delegated identities with real blast radius. That changes the governance problem from software security to privilege control, session control, and auditability. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime governance, not static trust.

The practical risk is that production access often accumulates faster than policy. A coding agent may be granted the same tokens, browser sessions, and repository credentials used by the human operator, even though its actions are faster, less predictable, and easier to chain across tools. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong indicator that agentic systems inherit the same structural weakness. In practice, many security teams discover overreach only after an agent has already touched production data or deployed a change that was never meant to be available at machine speed.

How It Works in Practice

Effective governance starts by treating the agent as a delegated identity tied to the human principal, then narrowing every permission to the smallest task window possible. That means short-lived tokens, per-task browser sessions, tightly scoped MCP connections, and explicit approval for any high-impact action such as deploy, delete, rotate, or exfiltrate. The strongest pattern is emerging around just-in-time privilege, where access is issued only when a task is approved and is automatically revoked when the task completes.

Security teams should also separate authentication from authorisation. Authentication proves the agent is the expected workload; authorisation decides what it may do right now. In practice, this is where workload identity becomes critical. Standards such as NIST Cybersecurity Framework 2.0 and implementation models like SPIFFE-style workload identity are better suited to agents than long-lived human credentials because they support cryptographic proof of identity without assuming a stable user pattern. Runtime policy engines can then evaluate intent, context, environment, and risk before granting a request.

  • Bind the agent to the human’s role, but do not inherit privileges the human does not already have.
  • Use just-in-time grants for privileged tools and revoke them on completion.
  • Scope secrets to a single task or session, not to the whole agent lifecycle.
  • Log every tool call, prompt-triggered action, and policy decision for incident review.

NHIMG research on the OWASP NHI Top 10 aligns with this approach: agentic systems need continuous control at the point of action, not just at onboarding. These controls tend to break down when the agent is allowed to reuse a human’s long-lived browser profile or a shared service account because attribution and revocation become ambiguous.

Common Variations and Edge Cases

Tighter control often increases operational friction, requiring organisations to balance speed against safety. That tradeoff is real for coding agents because engineers want low-latency assistance while security teams need deterministic guardrails. Current guidance suggests three common variants: low-risk read-only agents that can query repositories and logs; elevated agents that can propose but not execute changes; and high-impact agents that require human approval plus JIT credentials for production actions. There is no universal standard for this yet, so policy design usually depends on the sensitivity of the target environment.

Edge cases matter. Shared CI/CD identities, long-lived browser sessions, and embedded API keys in developer tooling are especially dangerous because they collapse individual accountability into one reusable credential. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a warning sign for any agent that can connect outward from production. For broader agent-risk mapping, the CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic AI Top 10 both reinforce the need to model tool chaining, lateral movement, and prompt-driven escalation, especially when the agent can interact with secrets managers or deployment systems.

In highly regulated environments, best practice is evolving toward explicit per-task approval, immutable audit trails, and emergency kill-switches for the agent’s tokens and sessions. That approach is more demanding, but it is the only reliable way to keep production access from turning into standing privilege.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 A2 Addresses insecure tool use and runtime escalation risks in coding agents.
CSA MAESTRO T2 Covers threat modeling for agent tool chaining and delegated execution.
NIST AI RMF GOVERN Supports accountability, oversight, and risk management for autonomous agents.

Require runtime checks and scoped tool permissions before any agent action reaches production.