An agent is not a user with a clever interface. It is a workload that can inherit intent, retrieve state and exercise authority across systems.
Traditional Zero Trust programmes were built around identities, endpoints, networks, applications and data. Agentic systems do not replace those layers; they create new ways to traverse them.
Microsoft’s August 2026 Zero Trust guidance for AI calls out agents, AI memory, developer tooling and autonomous workflows as new trust boundaries. Databricks’ emerging AI governance model similarly places models, MCP services and agents behind central privileges, policies and telemetry.
The common implication is architectural: security has to follow the action path, not just the login.
Identity must survive delegation
Suppose an employee asks an agent to change a supplier record. The agent may call an orchestrator, which invokes a specialised procurement agent, which accesses an MCP tool, which writes to an ERP.
There may be five identities in that chain:
- human requester;
- conversational agent;
- orchestrator;
- delegated agent;
- service principal or tool credential.
If the final write only records the service account, accountability is lost. If every downstream component inherits the employee’s full access, privilege can spread too far.
The correct pattern is scoped delegation: preserve who initiated the request, which agent is acting, which purpose was authorised and what subset of authority was delegated.
Least privilege becomes task-specific
A general employee role might permit reading hundreds of objects. An agent performing one workflow usually needs less.
Instead of granting “procurement access”, define capabilities such as:
- read supplier profile;
- read invoices for case X;
- propose bank-detail change;
- create draft update;
- request approval;
- commit approved update.
This is why tool design and security design converge. A giant generic ERP tool makes least privilege difficult. Small, semantically clear capabilities give the policy layer something meaningful to allow or deny.
Memory is a security boundary
Agent memory is operationally useful because it carries context across steps and sessions. It is also a new place for sensitive data, poisoned instructions and stale authority to persist.
A governed memory layer needs:
- provenance;
- purpose;
- retention;
- data classification;
- access control;
- revocation;
- separation between user preference and authoritative business fact;
- visibility into what is remembered and why.
“Remember everything” is not an enterprise memory strategy.
Verify continuously, not once
Zero Trust’s “verify explicitly” principle becomes dynamic for agents.
A tool call can be valid at 10:01 and invalid at 10:05 because:
- the case status changed;
- approval expired;
- source data became stale;
- the user lost access;
- the agent exceeded a spend limit;
- a risk signal changed;
- the action sequence entered a privileged state.
Policies therefore need runtime context. Authentication at session start is necessary and insufficient.
Assume breach means design containment
Agent failures and compromises should have a bounded blast radius.
Production controls can include:
- isolated execution;
- egress allowlists;
- short-lived credentials;
- tool-level permissions;
- transaction limits;
- reversible writes;
- human gates for privileged actions;
- rate limits;
- kill switches independent of the model;
- complete action traces.
A safe agent is not one that is assumed to behave. It is one whose misbehaviour remains containable.
Developer agents belong in the same model
Coding agents are particularly important because they can read source, propose dependencies, alter infrastructure and trigger deployment paths. Treating them as enhanced text editors understates their authority.
Source-code access, package allowlisting, secret handling, CI/CD permissions and software supply-chain controls should be explicit parts of the agent policy.
The developer experience may feel conversational. The security model should look like privileged automation.
The Lexdatum view
Zero Trust for AI is best understood as a control plane spanning identity, tools, memory, models, data and runtime behaviour.
The enterprise question is no longer only “Who are you?” It is:
Who asked, which agent is acting, for what purpose, with which delegated authority, against which current state, and what evidence will remain afterwards?
Once those answers travel with every action, autonomy becomes governable rather than merely powerful.
Sources
- Microsoft Security — Advance Zero Trust for AI: New tools and guidance to secure AI agents and DevSecOps (2026-08-04)
- Databricks — AI governance guide (2026-08-21)
Research note: This analysis is based on public information available on 1 September 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported claims are identified as such. This is not legal, security, financial or investment advice.