Why do AI agents increase risk when organizations reuse existing IAM and secrets practices?

Why This Matters for Security Teams

AI agents increase risk because they are not passive applications. They act, chain tools, and make runtime decisions that traditional IAM was never designed to govern. When teams reuse human-user patterns, such as static group membership, broad app roles, and long-lived API keys, they give autonomous workloads durable access that outlives the task. That creates standing privilege, weak accountability, and a larger blast radius when an agent is prompted, misconfigured, or compromised.

This is why guidance from OWASP Agentic AI Top 10 and NIST's NIST AI Risk Management Framework matters in practice: agents need tighter runtime controls, not just better onboarding. NHIMG research shows how quickly secret exposure becomes operational risk. In The State of Secrets in AppSec, GitGuardian and CyberArk found that the average time to remediate a leaked secret is 27 days, even though 75% of organisations report strong confidence in their secrets management.

In practice, many security teams encounter agent abuse only after a token has already been reused across systems, rather than through intentional least-privilege design.

How It Works in Practice

The safer model is to treat the agent as a workload identity, not as a human user. That means proving what the agent is with cryptographic identity, then authorizing what it may do at request time based on context, intent, and task scope. In many environments, that starts with workload identity primitives such as SPIFFE/SPIRE or short-lived OIDC tokens, paired with policy engines that evaluate each action as it happens. Current guidance suggests using real-time policy rather than pre-defined access rules alone, because agent behavior is dynamic and often unpredictable.

For secrets, the operational shift is just as important. Long-lived static credentials should be replaced with JIT issuance, short TTLs, and automatic revocation when the task ends. This reduces the chance that an agent can keep using credentials after the initiating workflow is complete. It also limits the damage from prompt injection, tool abuse, or lateral movement across SaaS platforms and internal APIs. The OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point toward the same operational outcome: reduce standing access, constrain tool reach, and log every privileged decision.

• Issue credentials per task, not per agent lifetime.
• Bind authorisation to context such as tool, data class, and destination.
• Revoke tokens automatically when the workflow completes or fails.
• Log agent intent, prompts, tool calls, and policy decisions for investigation.

These controls tend to break down in legacy environments where older apps only accept shared service accounts, coarse RBAC, or secrets embedded in CI/CD pipelines.

Common Variations and Edge Cases

Tighter controls often increase orchestration overhead, requiring organisations to balance faster agent delivery against stronger runtime governance. Not every agent needs the same posture. A read-only research assistant, a code-writing agent, and an autonomous remediation agent all create different risk profiles, so best practice is evolving toward tiered authorisation rather than one universal template. In lower-risk cases, short-lived tokens and scoped APIs may be sufficient. In higher-risk cases, policy-as-code, human approval gates, and step-up controls are more appropriate.

There are also environments where the standard answer becomes harder to apply. Shared enterprise platforms, vendor-managed connectors, and multi-agent workflows can make identity boundaries blur, especially when one agent delegates to another. Guidance is still maturing here, so organizations should treat cross-agent delegation, prompt chaining, and tool handoff as open governance problems rather than solved controls. NHIMG research on Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio shows how quickly agent workflows can turn into token theft or unauthorized action when assumptions about trust remain human-centric.

Where agents must act across many systems, the safest assumption is that any single secret, connector, or approval path can be misused unless it is explicitly time-bounded and context-bound.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more risk when they reuse existing credentials?
• Why are AI agents creating a new category of secrets risk?
• How can organizations prioritize high-risk AI agents?