Por qué el modelo de identidad de Zero Trust falla contra las acciones de IA de agentes

Zero Trust's core premise - verify every identity, validate every request, assume breach - falls apart when the actor isn't a human logging in but an agentic AI acting autonomously. The threat model centered on identity works fine for a developer pulling a database record or a service account hitting an API. Agentic AI doesn't retrieve data; it reasons, plans, and executes sequences of actions with compounding effects, often without a human in the loop.

Prompt Injection Breaks the Reasoning Layer

A malicious actor embeds instructions in data the agent will process - a document, an email, a web page - and those instructions redirect the agent's behavior. This is the agentic equivalent of SQL injection, but the compromise happens at the reasoning layer, not the identity layer. Zero Trust has no concept of a reasoning layer. It cannot verify that the instructions an agent follows are legitimate. That gap is fundamental.

Tool Misuse and Chaining Create Emergent Permissions

Agentic systems are given tools: API calls, database writes, email sends, code execution. In principle, least privilege applies. In practice, most implementations treat tool access as binary - the agent either has the tool or it doesn't. Context-dependent enforcement of when a tool should or shouldn't be used is rarely built at the security layer. Worse, in multi-agent architectures, one agent can invoke another, and the combined permission set exceeds what any individual access control list anticipated. Agent A has read access to financial records. Agent B has write access to external communications. If Agent A invokes Agent B, the emergent permission is effectively read and write - and nobody explicitly granted that combination.

What a Real Agentic Security Playbook Looks Like

Extensions to Zero Trust need to cover five areas. First, least privilege for actions, not just data - an agent handling customer inquiries should be able to read account records but not initiate refunds or send external communications unless explicitly scoped. Second, contextual action boundaries: static permissions aren't enough. An agent authorized to submit a credit application should not be authorized to submit fifty in sixty seconds, and an agent that normally reads a single customer record has no reason to enumerate all records with a single-character prefix. Third, reasoning transparency and audit chains: for high-stakes actions, capture not just the action but the reasoning chain - goal, data processed, intermediate decisions, tool call order. Fourth, human-in-the-loop checkpoints for decisions above a threshold: financial value, external communications, production configuration changes. Fifth, behavioral baselines: an agent's identity doesn't tell you whether it's behaving normally. Detect deviation in tool call frequency, data access patterns, and interaction sequences.

The stakes are concrete in domains like automotive financial technology. An agentic system touching a credit application pipeline has access to customer financial data, lender APIs, compliance rule sets, and deal submission workflows. A compromised agent doesn't just read sensitive data - it can submit fraudulent applications or manipulate deal terms through actions that look like normal system behavior. Zero Trust verifies the agent has credentials to call the lender API. It does not catch an agent that, due to prompt injection or misconfigured tool scope, calls that API with manipulated parameters on behalf of a malicious actor.

Teams that build agentic security thinking into their architecture now - rather than retrofitting after the first incident - will be in a much better position. Zero Trust secures the door. We still need to secure what happens after the agent walks through it.

Source: Zero Trust Doesn't Fully Solve the Agentic AI Problem
Domain: hackernoon.com