Why do AI agents create new risk when they can read email, query systems, and invoke tools on behalf of employees?

AI agents expand the attack surface because they can combine identity, data, and action in one runtime flow. If an agent is over-privileged, manipulated by prompt injection, or allowed to chain tools without oversight, it can exfiltrate data or perform unauthorized actions faster than a human reviewer can intervene. Runtime controls and least privilege are essential.

Why This Matters for Security Teams

AI agents are not just another app integration. They combine identity, access, data handling, and action in one runtime flow, which means a single compromise can become email exposure, system misuse, or tool-driven damage without a human clicking each step. That is why agent risk shows up as both identity risk and execution risk. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime controls, not static trust, as the safer model.

NHI Management Group research on AI Agents: The New Attack Surface report found that 80% of organisations say their agents have already acted beyond intended scope, including unauthorised system access, sensitive data sharing, and revealed credentials. That matters because agents are often deployed with employee-level permissions, then asked to infer intent and chain tools on the fly. In practice, many security teams encounter the abuse only after an agent has already queried, copied, or changed something that a human reviewer never intended.

How It Works in Practice

The core issue is that traditional IAM assumes a user or service has a fairly stable purpose. Agents do not. They can take a high-level goal, turn it into sub-tasks, and invoke multiple systems in sequence. That makes static role design brittle. A role that seems safe at provisioning time may become dangerous once the agent is allowed to search email, fetch documents, open tickets, call APIs, and write back to systems of record.

Better practice is emerging around intent-based authorisation, short-lived credentials, and workload identity. Instead of granting broad standing access, the agent should prove what it is through a workload identity such as SPIFFE or OIDC, then receive ephemeral credentials only for the task it is currently performing. Policies should be evaluated at request time, using context such as task, target system, data sensitivity, and whether the action is read-only or destructive. That aligns with the direction described in the CSA MAESTRO agentic AI threat modeling framework and in NIST guidance on AI governance.

Practical controls usually include:

• Just-in-time credentials with short TTLs, revoked automatically when the task ends.
• Tool-level allowlists that separate read, write, and administrative actions.
• Policy-as-code checks, using systems such as OPA or Cedar, before each high-risk action.
• Logging of prompts, tool calls, and data access for audit and incident response.
• Segregation between the agent’s reasoning context and sensitive secrets.

This model is reinforced by NHIMG reporting on the OWASP NHI Top 10, which highlights how agent credentials and tool access become attack paths when runtime controls are missing. These controls tend to break down when an agent is allowed to keep long-lived credentials, because the system can no longer distinguish one legitimate task from the next.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance faster automation against stronger guardrails. That tradeoff is real, especially in environments where agents support high-volume business workflows and interruptions are expensive. Best practice is evolving, and there is no universal standard for agent permissioning yet.

Some agents are intentionally read-only, such as assistants that summarize mail or search knowledge bases. Those still need controls, but the main risk is disclosure rather than direct system change. Other agents have tool use and write privileges, which raises the stakes because a single prompt injection can pivot from data exposure to action. The Gemini AI Breach and CoPhish OAuth Token Theft via Copilot Studio show why email, calendar, and OAuth-connected tools are especially sensitive.

Edge cases appear when agents span multiple tenants, handle regulated data, or operate inside workflows that require broad business judgment. In those settings, a simple allowlist is not enough. Security teams need human approval for irreversible actions, separate identities for each environment, and explicit revocation paths for every token issued to the agent. The industry still lacks a universal standard for how much autonomy is acceptable per risk class, so organisations should treat this as a governance decision, not just a technical one. Most failures happen when teams assume agent behaviour will stay predictable after deployment.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk even when they are short-lived?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?