Agentic AI breaks enterprise security at the cognition layer

At a glance

What this is: This is an analysis of why Agentic AI changes enterprise security by moving risk into the cognition layer, where tool use, database access, and code execution become identity and authorisation problems.

Why it matters: It matters because IAM, PAM, and NHI programmes must decide how to govern AI agents that act at runtime, not just authenticate them before use.

Context

Agentic AI introduces a new control gap because the system is no longer only generating text. It is deciding which tools to call, which data to query, and when to execute code, which makes identity and authorisation part of the runtime security boundary.

In that model, the problem is not simply malicious prompts or unsafe outputs. The enterprise must govern the cognition layer, where agent intent, tool access, and monitoring all need to line up before autonomous action occurs.

Key questions

Q: What breaks when agentic AI is governed like a normal application account?

A: Security controls break down because agentic systems do not behave like fixed-function applications. They can choose actions at runtime, combine tools in unexpected ways, and move faster than periodic review cycles. That means static roles, annual recertification, and one-time approvals do not fully describe the risk or contain the behaviour.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: How do security teams know if agentic AI controls are failing?

A: The main signs are session drift, repeated retry loops, unauthorized tool calls, and behaviour that diverges from the documented task sequence. If the agent keeps moving through steps after intent-to-tool alignment weakens, the system is drifting beyond its control envelope. In practice, teams should measure the full execution path, not isolated prompts.

Q: What should organisations do when an AI agent requests data or actions it is not permitted to use?

A: The correct response is to enforce the policy at the point of request, before the model or downstream tool receives the data. The decision should be recorded with the request, purpose, outcome, and governing policy so the organisation can prove why the action was denied or redirected. That evidence supports auditability, review, and future policy tuning.

Technical breakdown

Why the cognition layer changes the trust model

The cognition layer is the decision point inside an agent where it chooses tools, data sources, and actions at runtime. That is different from a normal application flow, where request paths are predefined and security teams can reason about permissions in advance. Once the agent can choose its own next step, static policy alone cannot describe the full risk surface. The result is a moving trust boundary between the model, the tool layer, and the data it can reach. Practical implication: treat the decision layer as a governed control point, not a passive AI output.

Practical implication: move authorisation checks to the point of agent decision, not only to the surrounding application.

MCP turns tool access into an identity problem

Model Context Protocol creates a standard way for agents to reach tools and enterprise data, but the protocol itself does not solve identity. If an agent runs under a generic service account or inherits a developer's privileges, the audit trail records the account, not the specific AI action chain. That makes attribution, least privilege, and accountability much harder to prove. The technical risk is not merely connectivity; it is delegated execution without a distinct identity boundary. Practical implication: bind every MCP call to a verified agent identity and scoped role.

Practical implication: require per-agent authentication and role scoping for every tool request made through MCP.

Runtime monitoring matters because agent behaviour is non-deterministic

Agentic systems can drift from expected behaviour during a session, especially when prompt injection or reasoning flaws cause an unexpected tool call or code execution. Static rules struggle here because the risky action may only become visible at the moment of execution. eBPF-style runtime controls are relevant because they observe what the process actually does, not what developers intended it to do. That is how teams catch an agent that suddenly reaches a new external IP or launches an unexpected shell command. Practical implication: monitor agent actions at runtime, not just model outputs or build-time policy.

Practical implication: pair policy enforcement with behavioural monitoring that can block anomalous agent actions in session.

Threat narrative

Attacker objective: The attacker aims to turn an AI agent into a high-privilege execution path for data theft, unauthorized actions, or financial fraud.

1. Entry begins when an attacker influences an agent through prompt injection or another reasoning flaw, causing the system to treat malicious input as a valid task.
2. Escalation occurs when the agent uses broad identity privileges to call tools, query data, or execute code beyond the original intent of the workflow.
3. Impact follows when the agent performs unauthorized actions such as data access, shell execution, or fraudulent transactions under an inherited account name.

Breaches seen in the wild

• Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cognition is becoming the new identity boundary: Agentic AI breaks the old assumption that identity ends at login and starts again at a tool request. Once the system can decide which action to take, the real security question is whether that decision is being made inside a governed identity boundary. That shifts the control plane from access checkout to action approval, which is a material change for IAM and NHI governance.

Verified agent identity is a prerequisite for accountability: A generic service account cannot explain which agent made which decision, and that destroys forensic clarity. The article's core point is not that agents need more access, but that broad inherited access removes the ability to attribute action to a specific AI runtime. Accountability becomes a first-class design requirement, not a post-incident reconstruction exercise.

Least privilege becomes a runtime problem, not a provisioning problem: Agent intent is not stable enough to be fully known at account creation time, which means traditional entitlement design breaks down faster in agentic systems. That is the governance assumption collapse here: least privilege was designed for predictable requesters, but autonomous behaviour changes the scope of access mid-task. Practitioners must rethink how privilege is defined when the actor can select its own next step.

Code to Cognition: The article usefully names a distinct control gap between secure code and secure infrastructure, but the real issue is the decision layer in between. Security teams have spent years hardening the runtime and the cloud, yet the agent can still misuse approved tools once cognition is outside direct control. The practitioner conclusion is that AI security has to include the decision chain, not just the model and the host.

MCP is an authorisation surface, not just a transport layer: The protocol creates a standard path to tools and data, which means every call becomes a high-value identity event. If the request is not authenticated, authorised, and attributed to a specific agent role, MCP simply amplifies existing privilege mistakes. The practical consequence is that agent governance must travel with the protocol path, or the protocol becomes the attack path.

From our research library:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Verified identity has to exist at the moment of action: Agentic systems do not leave enough room for delayed governance if the runtime can choose tools, query databases, and execute code in one session. That is why identity controls need to move closer to issuance and authorisation, not remain parked in post-hoc review cycles. The programme implication is simple: if the agent can act before review, the review model is already behind.

Runtime behaviour is now part of identity governance: The control question is no longer only who authenticated, but what the agent did after it authenticated. Security teams should expect to invest in behavioural policy, tool-scoped permissions, and monitoring that can distinguish normal summarisation from anomalous code execution. According to the 2026 Infrastructure Identity Survey, only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption. That gap will widen unless identity programmes treat agent actions as governance events, not just workload activity.

For practitioners

• Verify every agent identity Assign each AI agent a distinct identity instead of using a shared service account or a human developer's permissions. Tie that identity to the exact tools, data sets, and execution paths the agent is allowed to use.
• Scope MCP access by role Authorize each tool call based on the agent's role and the sensitivity of the target data, not on a generic application trust decision. Intercept every MCP request before the action reaches the tool layer.
• Add runtime behavioural controls Monitor for anomalous actions such as unexpected shell execution, new external connections, or database activity outside the agent's normal task pattern. Block or terminate the session when behaviour diverges from policy.
• Remove inherited developer privileges Separate deployment privileges from runtime privileges so the agent does not inherit the broad permissions of the person or pipeline that created it. Review which accounts currently overstate agent authority.

Key takeaways

• Agentic AI shifts security from prompt hygiene to governing the cognition layer where tools, data, and code execution converge.
• Generic service accounts and inherited developer permissions remove the agent identity needed for least privilege and accountability.
• Runtime monitoring and per-call authorisation are the controls most likely to limit damage when an agent behaves outside its intended scope.

Key terms

• Cognition Layer: The cognition layer is a practical way to describe AI workloads as part of the production attack surface. It covers the permissions, outputs, and runtime behavior of AI systems, including risks such as prompt injection, shadow AI, and data leakage through model responses.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Object-Scoped Authorisation: An access control model that binds permissions to specific records, resources, or business objects rather than to the endpoint alone. It requires the application to verify the subject, the object, and the transaction context before data is returned or modified.
• Runtime Behaviour Monitoring: Runtime behaviour monitoring is the practice of watching what an identity actually does during execution, not just what it was configured to do. For AI agents, this means tracking tool calls, session activity, data volume, and unusual action sequences so semantic abuse can be detected in flight.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.