What should teams do when AI agents become part of the attack surface?

Why This Matters for Security Teams

When AI agents become part of the attack surface, the issue is not simply that a new workload exists. The problem is that autonomous software can hold secrets, call tools, move laterally, and take actions faster than most review processes can detect. NHIMG’s AI Agents: The New Attack Surface report shows that 80% of organisations report agents acting beyond intended scope, while only 44% have any policy in place. That gap turns agent governance into an active exposure issue, not a future maturity exercise.

Security teams often miss the shift because they apply human IAM assumptions to non-human behaviour. An agent does not follow a stable access pattern, and it may chain prompts, APIs, and service accounts in ways that create unexpected reach. Guidance from the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 both point toward runtime governance, not static trust assumptions. In practice, many security teams encounter agent abuse only after secrets have been reused, data has been exfiltrated, or tool access has already been expanded.

How It Works in Practice

Teams should inventory every agent as a non-human identity and map four things: owner, permissions, secrets, and reachable data paths. That means documenting which systems the agent can query, which APIs it can invoke, which tokens it can present, and which downstream services inherit its trust. This is where workload identity matters. A cryptographic identity such as SPIFFE or an OIDC-based workload token proves what the agent is, while policy determines what it may do at request time.

For autonomous workloads, static role design is usually too coarse. An agent may need broad capabilities for one task and almost none for the next, so current guidance suggests just-in-time access, ephemeral credentials, and short TTLs rather than long-lived keys. That makes revocation easier when behaviour changes. It also reduces blast radius if the agent is induced to reveal secrets or call an unintended tool. NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs illustrates why exposed credentials are dangerous: attackers move quickly once they find usable material. The CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix both reinforce the need to model tool abuse, prompt injection, and lateral movement as operational threats, not theoretical ones.

• Assign a named business owner and a technical custodian to every agent.
• Replace standing secrets with scoped, short-lived credentials wherever possible.
• Evaluate authorization at runtime using policy-as-code, not pre-approved trust alone.
• Log every tool call, secret read, and data movement path for audit and rollback.

These controls tend to break down in high-autonomy environments where agents can spawn sub-agents, reuse browser sessions, or inherit privileges from orchestration layers that were never designed for machine-speed chaining.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance faster task completion against stronger containment. That tradeoff is especially visible in developer copilots, customer support agents, and multi-agent pipelines, where excessive restriction can break workflows and too much access can expose sensitive systems. There is no universal standard for this yet, so current guidance suggests starting with task-scoped access and expanding only when evidence supports it.

Some environments need extra caution. Shared service accounts can blur accountability, browser-using agents can inherit session state, and data-rich retrieval agents may access records far outside their original intent. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both show that weak ownership and poor secret hygiene remain recurring failure modes. For agentic systems, the practical response is to treat any unclear access path as a live control gap and to retire privileges the moment the task ends.

Where agents interact with regulated data or production systems, teams should combine NIST control mapping with incident-ready containment. That means isolating tool credentials, segmenting network reach, and being ready to disable the agent without affecting the underlying platform. In this domain, best practice is evolving quickly, so governance should be reviewed as often as the agent’s capabilities change.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should teams govern AI agents that use MCP?
• 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?