Zero-Trust AI Agents: Why Intent Matters More Than Tool Syntax

A tool call can be perfectly formed and still be unauthorized.

The schema can match. The parameters can have the correct data types. The agent can hold a valid connection to the target system. None of those facts answer the question that matters in production: should this action happen now?

That is the difference between syntax validation and runtime authorization. Syntax validation asks, “Is this call well-formed?” Authorization asks, “Should this action happen?” The first is a format question. The second is an authority question.

This distinction is becoming central to enterprise AI security. In its September 15, 2026 article, Google Developers Blog describes zero-trust agents that judge intent, not just syntax. The operational requirement is clear: evaluate the agent’s proposed action at runtime, before it changes data, moves money, or triggers a business workflow.

Preview

Most agent security controls stop at schema validation, tool allowlists, or connection-level permissions. Those controls establish what an agent can technically call. They do not establish whether the specific operation, with its parameters, purpose, value, identity, and workflow state, is authorized.

Zero-trust AI agents require a different control point: map the action surface, evaluate the proposed intent, authorize the operation, and record the decision.

1. Why agent security started with syntax

The first generation of agent integrations needed a reliable way to connect models to software. Tool schemas provided that structure.

A schema defines the operation name, required fields, accepted types, and expected response. An MCP tool definition describes what a server exposes. A tool allowlist limits which integrations an agent may discover. Connection-level permissions determine whether the agent can reach a particular service.

These controls remain necessary. They prevent malformed requests and reduce accidental exposure. They answer important questions:

• Does the request contain the required fields?
• Does the value match the expected type?
• Does the tool exist?
• Does the agent have a connection to the service?
• Is the requested operation exposed by the integration?

But they do not answer the authority question.

A payment request with a valid numeric amount is syntactically correct. A vendor update with a valid account number is syntactically correct. A bulk export with a valid filter is syntactically correct.

Valid syntax is not valid authority.

2. Why syntax breaks down in enterprise workflows

The same operation can be benign or consequential depending on its context.

Consider an accounts payable agent. It has a tool called create_payment. The schema accepts a vendor ID, invoice ID, amount, and currency. Every field is valid.

The action still requires more evaluation:

• Is the amount within the agent’s delegated limit?
• Is the vendor’s bank account newly changed?
• Is the invoice already approved?
• Did this agent create the invoice?
• Is the payment going to a restricted counterparty?
• Does the workflow require a human approval?
• Is the agent acting for an authorized employee?

The schema cannot answer those questions.

The same problem appears across the enterprise:

• A refund below a threshold may proceed automatically. The same refund above the threshold may require approval.
• A vendor bank-account change may be validly formatted but blocked until independent verification occurs.
• A bulk record export may use a valid query while violating data-purpose or volume restrictions.
• An HR record update may be technically permitted but prohibited when it changes compensation or employment status.
• An accounts payable agent may be allowed to create a payment proposal but prohibited from approving the same proposal.

The operation name does not define the risk. The intent and context define the risk.

3. Syntax validation and runtime authorization are different controls

The distinction should be explicit because the controls operate at different moments and produce different outcomes.

Control	Syntax-level validation	Runtime intent-based authorization
What it evaluates	Schema, fields, types, tool existence	Agent identity, delegated user, operation, parameters, purpose, value, workflow state, policy
When it acts	When the request is parsed or routed	After the agent proposes the action and before the tool executes
What it asks	“Is this call well-formed?”	“Should this action happen?”
How it decides	Schema rules, type checks, allowlists	Deterministic policy evaluation and scope verification
What it produces	Valid or invalid request	ALLOW, BLOCK, or ESCALATE, with evidence

Syntax validation protects the interface. Runtime authorization protects the business action.

4. What zero trust requires from an AI agent

Zero trust does not mean adding another prompt instruction that tells the agent to be careful. It means removing implicit trust from the action path.

A production agent needs at least six distinct controls.

1. A distinct agent identity

The agent is not the user. It is software acting on behalf of a user or business process. Its identity must be independently visible and enforceable.

The authorization record should identify:

• Which agent proposed the action.
• Which user or service delegated the task.
• Which system and operation were targeted.
• Which credentials or execution identity were used.

A user’s permission must not silently become the agent’s unlimited authority.

2. Delegated authority and scope verification

The system must verify that the user can request the action and that the agent is allowed to perform it.

Those are separate checks. A finance manager may be allowed to approve a payment manually while a payment-classification agent is allowed only to read invoices and create proposals.

3. Purpose-bound and trusted-path context

Context carries authority. An agent should not be allowed to use sensitive data for a purpose unrelated to the task that provided access to it.

Trusted-path policies determine where enterprise context may travel. Purpose-boundary policies determine why the agent may use it. A customer record retrieved for support should not automatically become input for an unrelated marketing export.

4. Operation-level least privilege

Connection-level access is too broad. An agent connected to a finance system may see operations for reading invoices, changing vendors, releasing payments, and approving transactions.

Least privilege must apply to the operation, not merely the server.

LangGuard’s least-privilege guidance describes the required distinction: an agent may read invoices without being authorized to approve them.

5. Deterministic evaluation before execution

The policy decision must occur before the tool call reaches the system of record. Monitoring the action after execution is not authorization.

The control point must return one of three outcomes:

• ALLOW: the action is within scope and policy.
• BLOCK: the action violates scope, policy, or a control boundary.
• ESCALATE: the action is held for a named human approver.

Safe actions proceed automatically. Exceptional actions receive targeted control.

6. Named human approval for high-risk actions

High-value, irreversible, regulated, or SoD-sensitive actions require a person who can be identified by name and role.

“Human oversight” is not a generic notification. The action must remain on hold until the authorized approver allows or denies it.

5. Determinism matters more than a risk score

Probabilistic scoring can help identify unusual behavior. It does not replace authorization.

A risk score might say that an action appears suspicious. It does not provide a reproducible rule for whether the action may execute. Two identical requests should not produce different authorization outcomes because a model’s confidence shifted.

A deterministic runtime control evaluates the same inputs against the same policy and returns the same decision:

1. Identify the agent and delegated user.
2. Identify the operation and parameters.
3. Evaluate purpose, scope, value, data, workflow state, and history.
4. Return ALLOW, BLOCK, or ESCALATE.
5. Record the complete decision.

The decision must also be explainable and replayable. An auditor should be able to ask which policy applied, what the agent attempted, who approved it, and why the system allowed or stopped it.

Not a signal. A decision.
Not a reconstruction. Evidence.

6. Segregation of duties must apply to agents

Segregation of Duties (SoD) is not solved by giving an agent a narrow role. SoD controls the combination of actions performed by the same actor.

An accounts payable agent may legitimately create a payment proposal. It should not approve that same proposal. If it can create and approve the transaction, the workflow has lost an independent control even if both operations are individually permitted.

The authorization system must evaluate history and relationships:

• Who created the transaction?
• Who changed the vendor details?
• Which agent performed the earlier operation?
• Does the current action cross an SoD boundary?
• Is independent approval required?

The result may be BLOCK when the combination is prohibited or ESCALATE when a named approver must decide.

Least privilege limits capability. SoD limits combinations. You need both.

7. A practical implementation checklist

Use the following stages to move from connection-level trust to zero-trust runtime control.

Stage 1: Map the action surface

Create an inventory of:

• Every agent.
• Every connected MCP server and tool.
• Every exposed operation.
• Every reachable system of record.
• Every data class and business workflow affected.

SCOPE-MCP supports design-time action-surface mapping and capability classification. The output is a concrete scope, not an assumption about what the agent should do.

Stage 2: Classify capabilities against policy

Classify each operation by:

• Read or write impact.
• Financial or operational value.
• Data sensitivity.
• Regulatory relevance.
• Reversibility.
• SoD implications.
• Required human approval.

Map those classifications to applicable controls and frameworks. The NIST AI Risk Management Framework provides a lifecycle structure through GOVERN, MAP, MEASURE, and MANAGE. ISO/IEC 42001 establishes requirements for an AI management system. OWASP LLM06:2025 Excessive Agency specifically emphasizes minimizing functionality, permissions, and autonomy.

Stage 3: Define intent and purpose boundaries

Write policies that describe the business action, not only the API shape.

Define:

• What the agent is allowed to accomplish.
• Which data it may use.
• Which operations support that purpose.
• Which values require approval.
• Which context may move between systems.
• Which actions are prohibited regardless of model output.

Stage 4: Enforce before execution

Place authorization between the agent and the tool. Evaluate every consequential call before the downstream system receives it.

LangGuard Arbiter is built around this pre-execution action layer: evaluate the proposed operation, return ALLOW, BLOCK, or ESCALATE, then permit execution only when policy authorizes it.

Stage 5: Route exceptions to named approvers

Define approval thresholds for:

• Financial value.
• Sensitive data.
• Irreversible changes.
• Regulated systems.
• SoD conflicts.
• New or unclassified operations.

Hold the action until the approver makes an explicit decision.

Stage 6: Preserve replay-ready evidence

Record the complete chain:

• Agent identity.
• Delegated user identity.
• Requested operation.
• Parameters and relevant context.
• Policy evaluated.
• Decision returned.
• Timestamp.
• Approver identity and decision, when applicable.
• Result of execution.

A log line says that something happened. Evidence shows who acted, what authority applied, and why the action proceeded.

8. The question production teams must answer

The old question is: Did the agent call the right tool?

That question is necessary but insufficient. It checks syntax, routing, and integration behavior.

The production question is: Was the agent authorized to take this action, and can you prove it?

That requires a different architecture. You must map the action surface, evaluate intent and context, authorize the operation before execution, and record the decision for review.

This is the control layer that turns agent access into accountable authority. It does not replace existing identity, API, schema, or network controls. It operates above them, at the point where an agent attempts to change the business.

Zero trust for agents is not trust in a better tool definition.

It is authorization before execution.