Why do agentic systems complicate AppSec and IAM at the same time?

Why This Matters for Security Teams

Agentic systems collapse a boundary that security programmes have historically depended on: application logic on one side, identity and privilege on the other. Once an agent can decide, invoke tools, and act on production data, the risk is no longer limited to code flaws or misused accounts in isolation. It becomes a joint problem of control integrity, authorisation scope, auditability, and safe delegation. Guidance in the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward the same issue: trust in agent behaviour must be engineered, not assumed.

The practical challenge is that AppSec teams often evaluate prompts, model inputs, and software dependencies, while IAM teams evaluate roles, service accounts, and access policies. For agentic systems, that split leaves gaps. An apparently harmless tool call can become a privileged action if the agent inherits broad permissions, and a well-locked-down identity layer can still fail if the application allows unsafe instruction-following or weak output handling. In practice, many security teams encounter this only after an agent has already executed an unexpected action, rather than through intentional control design.

How It Works in Practice

Security teams need to treat an agent as both an application component and a delegated actor. That means the control plane should describe what the agent is allowed to do, while the application plane should constrain how it reasons, what it can retrieve, and when outputs are allowed to trigger action. Current best practice is evolving, but the operational pattern is clear: build explicit approval paths for high-impact actions, limit tool scope to the minimum necessary, and preserve a complete trail from user intent to model output to executed side effect.

The most common implementation pattern includes:

• Binding each agent to a distinct non-human identity, rather than sharing human admin accounts or generic service credentials.
• Using short-lived, narrowly scoped credentials for tool access, ideally with step-up checks for sensitive actions.
• Logging prompts, retrieval results, tool invocations, policy decisions, and downstream changes in a way that can be correlated in SIEM.
• Applying model and output validation so that an agent cannot convert a malformed instruction into an unsafe action without review.
• Separating development, test, and production access so that agent behaviour in one environment does not inherit trust in another.

This is where AppSec and IAM overlap most sharply. AppSec protects the integrity of the model, prompts, orchestration layer, and dependencies. IAM protects the authority behind the actions. The two disciplines need a shared trust boundary, otherwise the organisation cannot answer a simple but critical question: did the agent merely suggest the action, or did it have the rights to perform it? The same concern appears in threat modelling guidance such as the CSA MAESTRO agentic AI threat modeling framework and adversarial AI mapping in MITRE ATLAS adversarial AI threat matrix.

These controls tend to break down when an agent is allowed to chain multiple tools across a hybrid environment because privilege sprawl and incomplete telemetry make the final action hard to attribute.

Common Variations and Edge Cases

Tighter agent controls often increase operational friction, requiring organisations to balance automation speed against review overhead. That tradeoff is real, especially where teams want autonomous triage or self-healing workflows. There is no universal standard for how much autonomy is acceptable, so the right answer depends on data sensitivity, action severity, and the blast radius of failure.

Some environments need a more conservative model. In regulated workflows, financial systems, or infrastructure operations, agents should usually be constrained to recommendation mode unless the action is low risk and reversible. In broader cyber terms, that aligns with control discipline described in NIST Cybersecurity Framework 2.0 and implementation detail from NIST SP 800-53 Rev 5 Security and Privacy Controls. Where an agent is reading from one system and writing to another, the safest model is often “observe broadly, act narrowly.”

Edge cases usually appear when teams assume a single control owner. If AppSec owns the model but IAM owns the credentials, neither side may notice that the other has created an unsafe pathway. The same issue shows up with federated tooling, shadow APIs, and delegated access to SaaS platforms. In those environments, current guidance suggests joint governance, shared logs, and explicit approval thresholds, rather than relying on either discipline alone. For teams mapping AI governance maturity, the NIST AI Risk Management Framework remains the cleanest way to frame ownership across both domains.

Related resources from NHI Mgmt Group

• Why do agentic AI systems complicate existing IAM and PAM controls?
• Why do agentic AI systems complicate IAM and IGA programmes?
• Why do AI coding agents change AppSec and IAM governance at the same time?
• Why do agentic AI systems change IAM risk?