How does agentic AI risk differ from traditional automation risk?

Traditional automation runs scripted sequences against well-defined APIs. The actions are predictable. The risk is operational (failure modes in the script) and security (credential exposure for the automation service account). Agentic AI introduces non-deterministic action selection. The agent decides which action to take based on its reasoning. The risk register has to account for unintended action selection in addition to the operational and credential risks.

Does running an agent in a sandboxed environment mitigate the risks?

Sandboxing limits the blast radius for some failure modes (the agent cannot reach beyond the sandbox's network boundary or filesystem). It does not eliminate the per-action authorization question inside the sandbox. An agent that has legitimate access to a customer database can still take an unauthorized action against the database from inside the sandbox. Sandboxing is one layer; per-action policy enforcement is another.

What about agents that operate against the organization's internal APIs only?

The internal-only deployment narrows the blast radius but does not change the per-action authorization question. The agent still acts on behalf of users with varying permissions. The internal APIs typically grant the agent broad access through a service credential. The authorization decision per action is the same question whether the targets are external or internal.

How does prompt injection figure into agentic risk specifically?

Prompt injection in an agentic system can alter the action the agent takes, not just the response the agent returns. An injection that redirects the agent to take a different action against a different target is the agentic version of the failure mode. The control is at two layers: input sanitization (which can fail for novel injection techniques) and per-action authorization (which catches the injection's effect by evaluating the action against the policy regardless of how the agent arrived at it).

What is the order of operations to mature an agentic AI risk program?

Catalog the agents and the actions each is authorized to take. Identify the failure modes by use case. Map the controls from the applicable frameworks. Deploy the per-action enforcement layer for the highest-risk agents first. Validate the audit evidence the layer produces against the regulatory expectations. Expand coverage to the broader agent fleet. The pattern is similar to other risk programs; the agentic specificity is in the per-action surface.

Agentic AI Risk: Mapping the New Failure Modes to Enterprise Controls

Agentic AI systems extend the AI risk surface beyond the chatbot's read-and-respond shape to the agent's act-on-the-world shape. The chatbot can leak data through its response. The agent can take an action that the user did not authorize, against a system the user does not have permission to modify, with consequences the deploying organization is accountable for.

The risk register has to extend. Data leakage and prompt injection still apply. New failure modes - unauthorized action execution, identity escalation through static credentials, action lineage gaps, downstream system impact - get added. The existing control frameworks (EU AI Act, NIST AI RMF, ISO 42001, SR 11-7, HIPAA) reach the new failure modes with varying directness.

I want to walk through the agentic failure modes, the controls that apply, the gap the existing frameworks leave, and the architectural primitive that closes it.

The new failure modes

Unauthorized action execution

The agent takes an action that the user did not authorize. The mechanism may be prompt injection in the input data, an unintended interpretation of the user's instruction, or the agent's reasoning chain producing a different conclusion than the user expected. The action executes against a downstream system because the agent has credentials and the credentials authorize the call.

The blast radius depends on the actions the agent is provisioned to take. An agent that can email externally, change CRM records, modify configurations, transfer funds, or escalate access has higher blast radius than an agent restricted to read-only operations on a single system.

Identity escalation through static credentials

The agent runs under static service credentials that grant the agent more permissions than the originating user has. When the agent acts on behalf of a low-privilege user, the agent can still take high-privilege actions because the credentials grant them. The downstream system sees the agent's identity, not the user's, and authorizes accordingly.

This is the classic confused deputy at the agent layer. The agent does not know it is being asked to act on the user's behalf for an action the user could not perform directly.

Action lineage gaps

The audit trail of what the agent did, for whom, under what policy, with what data, is incomplete. The agent's own logs capture some of the chain. The downstream system's logs capture some. The application that invoked the agent captures some. None of them, separately or in aggregate, reconstruct the per-action evidence the regulatory frameworks expect.

The gap shows up when an incident occurs and the investigator needs to trace what happened. The reconstruction takes hours or days of correlation across multiple systems and still cannot establish the policy that was in effect at the moment of the action.

Downstream system impact

The agent operates against downstream systems that were designed for human users at human pace. The agent operates at machine pace and can produce volumes of actions, queries, or updates that the downstream system was not provisioned to handle. The impact ranges from operational (rate-limit violations, queue saturation) to data integrity (concurrent modifications, race conditions) to security (denial of service, privilege amplification).

Cross-agent contamination

In multi-agent deployments, one agent's behavior can affect another's. An agent that produces poisoned output (whether through prompt injection or hallucination) and passes it to another agent for further processing propagates the failure. The originating identity of the request is the same, but the action chain becomes harder to constrain at the policy layer.

Tool poisoning

The agent's tool catalog (the set of capabilities the agent can invoke) is itself a risk surface. A tool definition that misrepresents what the tool does, a tool that fetches malicious content, or a downstream API that returns adversarial output can subvert the agent's behavior. The OWASP LLM Top 10 places aspects of this under LLM03 (training data poisoning) and LLM07 (insecure plugin design) in older versions; the agentic application of the principle is broader.

How existing controls apply

EU AI Act

For agents operating in high-risk Annex III use cases (credit scoring, employment, education, biometrics, critical infrastructure, law enforcement, border control, justice), Article 12 logging applies to the system's events over its lifetime. The Act does not specify the per-action granularity, but the events include the AI system's decisions and the audit requirements extend to the actions the agent takes that are part of the decision process. The August 2, 2026 deadline applies. Article 99 sets the penalty at 15 million EUR or 3% of global turnover.

NIST AI RMF

The MEASURE function calls for continuous monitoring of AI system operation. For agentic systems, the monitoring covers the actions the agent takes. The MANAGE function calls for response to identified risk. The agent-specific identity and authorization framework codifies the three-pillar pattern: agent identity, delegated authority, action lineage.

ISO 42001

The AI management system requirements cover policies, controls, and ongoing operation. For agentic deployments, the management system has to enumerate the agents, the actions each is authorized to take, the controls that prevent unauthorized actions, and the evidence the controls operate as designed.

SR 11-7 (model risk management)

For financial institutions, SR 11-7 applies to AI-assisted decisions. The agent's actions are extensions of the model decisions. The validation, ongoing monitoring, and audit functions need access to the per-action records.

HIPAA

For healthcare deployments where the agent processes PHI, the BAA chain extends to the agent's downstream services. The audit log requirements under the security rule apply to the agent's accesses to PHI. The minimum-necessary principle applies to the data the agent uses in each action.

Fannie Mae LL-2026-04

For mortgage lenders, the disclosure-on-demand obligation covers the AI tools and the actions the AI takes in origination and servicing. Effective August 6, 2026, the lender has to be able to produce the records of how the AI handled specific transactions.

The gap the frameworks leave

The frameworks apply at the policy and control level. They specify what the organization has to do at the management system level. They do not specify the per-action evidence shape the new failure modes need.

The gap is most visible in the chatbot-shaped audit log applied to an agentic system. The log captures the user's prompt and the model's response. The log does not capture each downstream action the agent took, the authorization decision at each step, or the policy version in effect when the action executed.

The architectural primitive that closes the gap is per-action evaluation at the agent-to-service boundary. Each action call from the agent to a downstream service passes through an enforcement point. The point evaluates the action against the user's authorization scope, the data classification of the target, and the policy in effect. The decision is recorded. The action either executes or returns the policy decision.

DeepInspect

This is the architecture DeepInspect provides. DeepInspect sits at the AI request boundary as a stateless proxy. For an agentic deployment, the proxy covers both the inbound prompt to the model and the outbound action calls from the agent to downstream services. Identity binding from the corporate IdP. Per-action authorization against the user's scope, not the agent's static credentials. Per-decision audit record under the deployer's control.

The failure modes map to the architecture. Unauthorized action execution: blocked at the policy decision point. Identity escalation: prevented because authorization decisions use the user's identity, not the agent's. Action lineage gaps: closed by the per-decision record. Downstream system impact: throttled and gated at the proxy. Cross-agent contamination: the per-action evaluation runs at each agent-to-agent or agent-to-service boundary. Tool poisoning: the action calls and their parameters are evaluated at the wire.

For the EU AI Act readiness, the per-action records satisfy the Article 12 obligation. For NIST Pillars 2 and 3, the proxy is the implementation of delegated authority and action lineage. For SR 11-7 and ISO 42001 audits, the records are the evidence the auditor samples against.

If your agentic deployment is in production and the per-action evidence layer is unbuilt, the risk register is recording failure modes that the existing controls do not catch. Let's talk today.