How should security teams govern AI agents that use service accounts and MCP tools?

Why This Matters for Security Teams

AI agents with service accounts and MCP tools are not just another workload. They can decide which tool to invoke, chain actions, and operate outside the exact path a human reviewer imagined. That changes governance from static permissioning to runtime control. Current guidance suggests teams should combine ownership, attribution, and containment, because a service account alone does not explain intent, and a tool list alone does not constrain abuse. NHI management needs to account for the agent as an autonomous actor, not a passive app.

That is why controls around agent identity, ephemeral secrets, and tool scoping need to be treated as part of one system. NHIMG has documented how agentic behaviour expands the attack surface in OWASP Agentic Applications Top 10, while NIST frames the broader governance problem through the NIST AI Risk Management Framework. In practice, many security teams encounter misuse only after an agent has already called an unapproved tool or touched data outside its intended scope, rather than through intentional design review.

How It Works in Practice

Governance starts by separating three layers: the human owner, the workload identity, and the tool permissions. The human owner is accountable for the agent’s purpose and approval. The workload identity proves what the agent is at runtime, ideally using workload identity patterns rather than long-lived shared secrets. The permission layer defines what the agent can do, and it should be evaluated at request time, not only during provisioning. That is where intent-based authorisation becomes important: the policy engine should ask what the agent is trying to do, which data it is targeting, and whether the action matches the approved task.

For service accounts, best practice is evolving toward JIT credential provisioning and short TTL secrets. Long-lived tokens create a standing path to abuse if the agent is hijacked, duplicated, or given a new objective. MCP environments need especially tight tool scoping because servers often expose broad capabilities by default. The Astrix research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which underscores how often governance lags implementation. Align that with the CSA MAESTRO agentic AI threat modeling framework and the OWASP Top 10 for Agentic Applications 2026 to map risks such as tool misuse, overreach, and indirect prompt or action chaining.

• Issue the agent a unique workload identity, not a shared team credential.
• Bind permissions to the current task, not to a broad job role.
• Use short-lived secrets with automatic revocation after task completion.
• Log every tool call, downstream call, and policy decision for auditability.
• Block tool chaining that crosses trust boundaries unless explicitly approved.

These controls tend to break down when MCP servers are treated as trusted internal plumbing and agents are allowed to inherit human-like access without request-level policy checks.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance agility against containment. That tradeoff is real, especially where agents support developer productivity or customer-facing workflows. In those environments, current guidance suggests using step-up approval for sensitive actions instead of fully blocking autonomy. For example, an agent may be allowed to draft, retrieve, or summarise by default, but require JIT elevation before writing, deleting, exporting, or invoking a second privileged tool.

There is no universal standard for this yet, so teams should avoid pretending that one policy model fits every agent. A code assistant, a SOC triage agent, and a business-process agent will each need different boundaries. NHIMG’s Analysis of Claude Code Security is a useful reminder that tool-enabled agents need purpose-built controls, not generic IAM templates. For broader governance context, the NIST AI Risk Management Framework supports accountability and measurement, while NHIMG’s Lifecycle Processes for Managing NHIs helps teams connect provisioning, review, rotation, and revocation. The main exception is highly regulated or safety-sensitive environments, where agent autonomy may need to be sharply constrained or removed entirely.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How can organisations govern AI agents that use service accounts and tokens?
• How should security teams govern AI agents that can access enterprise systems?