Zero Trust Covers the Login, Not the Agent

Applying zero trust to AI means treating every prompt, model and agent identity as untrusted until it proves otherwise.
 

For 20 years, zero trust meant one thing: stop assuming anyone inside the network perimeter deserves access just because they got past the login screen. Verify the user, verify the device, grant the narrowest access that gets the job done, then keep checking. It worked because the thing being verified, a person at a keyboard, behaved in ways security teams could predict and log.

AI does not behave that way. A single prompt can trigger a chain of tool calls across a dozen systems in seconds. An agent can read a file, summarize it and forward the summary to an external address before a human ever reviews what happened. The identity making all of this happen might not be a person at all. It might be a service account nobody remembers creating.

Zero trust is not obsolete here. It is underused. The principles that secured human access for two decades, verify explicitly, enforce least privilege, assume breach, apply just as well to AI. The problem is that most organizations stopped extending those principles at the login screen, right when AI needed them to go further. Boards and regulators have started noticing the gap too, and evidence of AI governance is quickly becoming something they expect to see on request, not something they take on faith.

The Trust Boundary AI Keeps Walking Through

Traditional access control assumes a predictable subject. A human logs in, the system checks role and device posture, and access holds for the length of that session. AI agents break that assumption in three specific ways.

First, the identity layer multiplies. Non-human identities, service accounts, API keys, bots and now autonomous agents, already outnumber human identities by 144 to 1 in cloud-heavy environments, according to Cloud Security Alliance research. Each one is a potential access point that most identity programs were never built to track.

Second, agent behavior cannot be fully tested before deployment. A human's job description sets rough boundaries on what they might do day to day. An agent's behavior is determined at runtime: by the prompt it receives, the data it retrieves and the tools available to it in that moment. Two identical prompts can produce different tool calls depending on what the agent finds along the way.

Third, every tool an agent can call becomes a new point where trust gets assumed rather than verified. A finance agent that can also query HR records is not one trust boundary. It is two, collapsed into something that looks like one on a dashboard.

None of this means zero trust fails for AI. It means zero trust's usual stopping point, the login screen, is no longer where the risk lives.

Zero Trust Didn't Need Replacing, It Needed Extending

The core of zero trust has not changed since the model matured: trust nothing by default, verify every request on its own merits, grant the minimum access needed and assume a breach has already happened somewhere in the environment. Those ideas, drawn from the same zero trust architecture principles codified in NIST SP 800-207, apply to a prompt and a service account exactly as well as they apply to a laptop and a badge.

Even vendors outside the data security space are starting to say the same thing out loud. Microsoft recently extended its own zero trust reference architecture to cover AI agent behavior end to end, treating it as an addition to an existing program rather than a separate discipline. That is the right instinct, and it is one Forcepoint's data security practice has operated on for years.

Forcepoint built its zero trust position on the data, not the network edge: classify what's sensitive, apply least-privilege access to it and monitor continuously rather than trusting a single point-in-time check. Extending that discipline to AI agents is not a pivot. It's the same model, pointed at a new kind of identity.

What changes with AI is not the principle. It's where the principle has to apply. Zero trust for AI means pushing verification past the network and the login screen, into the prompt itself, the data an agent can reach and the identity behind every agent action.

Treat Every Prompt Like an Unverified Request

Every prompt that reaches a model is a request, whether it comes from an employee typing a question or an agent passing context to itself mid-task. Under zero trust, a request gets inspected before it's trusted, not after.

In practice, that means applying the same content inspection to prompts that organizations already apply to outbound email and web traffic. A prompt containing a customer record, a source code snippet or a contract number should get flagged, redacted or blocked before it leaves the user's control, the same way it would if someone tried to paste it into a personal email account. Forcepoint AI Data Security applies this logic by extending existing DLP classification to prompts and agent responses, so a policy built to stop data loss in email stops it in a chat window too, without a separate taxonomy to maintain.

This matters as much for what an agent generates as what a user types. A response pulled from a sensitive data source carries the same risk leaving the model as it did sitting in the source system. Zero trust for AI treats both directions, input and output, as untrusted until policy says otherwise.

Extend Least Privilege to the Data an Agent Can Reach

Least privilege has always meant giving a user the smallest set of permissions that lets them do their job. Applied to AI, the question shifts slightly: not what can this agent do, but what data can it reach if something goes wrong.

Most agents inherit permissions from whoever deployed them, which usually means far more access than the task requires. An agent built to summarize support tickets does not need the ability to read every file in a shared drive, but if it was handed a service account with broad access, that's exactly what it can do. The fix starts before the agent ever runs: classify sensitive data, find where overshared files and excess permissions already exist and close that gap first. Forcepoint DSPM handles this discovery and classification work, so least privilege has something accurate to enforce against instead of a guess.

Once data is classified, access scoping follows the same zero trust logic as everything else: default to no access, grant narrowly and revisit the grant when the agent's task changes. An agent's permissions should look nothing like the broad role a human in the same department would hold.

Give Every Agent Its Own Identity, Not a Shared Credential

Shared service accounts are convenient, and they are exactly what zero trust exists to eliminate. When multiple agents or scripts authenticate with the same credential, nobody can say with confidence which agent did what, and revoking access for one means breaking it for all of them.

Zero trust for AI means registering each agent as its own identity: scoped to a defined set of approved tools, authenticated separately from every other agent and reauthenticated continuously rather than trusted for the length of a session. Credentials should be brokered, not handed out. An agent that never holds a standing credential to the applications it calls cannot leak one, intentionally or otherwise, and a compromised or misbehaving agent can be revoked instantly without touching the credentials every other agent depends on. This is the model behind Forcepoint AI Agent Gateway, which sits between agents and the business applications they call, issuing short-lived tokens instead of standing access and holding sensitive writes or deletes for human approval before they execute.

The goal is the same one zero trust has always had for human identity: know exactly who, or what, is acting, and make sure that knowledge survives the moment something goes wrong.

That accountability gap is becoming a compliance problem as much as a security one. Frameworks including the EU AI Act, NIST AI RMF and SEC disclosure rules are starting to require organizations to show, not just claim, that AI systems operate within defined limits. A zero trust approach produces that evidence as a side effect of normal operation: every verified identity, every scoped access grant and every logged action becomes part of the audit trail regulators are starting to ask for. Organizations trying to assemble that evidence after the fact, from logs that were never designed to answer the question, tend to find the gaps exactly when a regulator or a board member asks.

A Practical Sequence for Putting This to Work

Most of the failures above come from skipping steps, not from picking the wrong tool. A workable rollout follows roughly this order:

1) Inventory every agent and the identity behind it. You cannot govern what you have not counted. Start with a list of every agent, bot and service account with access to production data.

2) Classify the data before agents reach it. Know what's sensitive before an agent can touch it, not after an incident reveals it.

3) Scope each agent to the narrowest set of tools it needs. Resist giving an agent broad access because it might need it later.

4) Broker credentials instead of issuing them. No agent should hold a standing password or API key to a business application.

5) Gate sensitive actions behind human approval. Reads can often run autonomously. Writes and deletes to sensitive systems should not, at least not yet.

6) Log every action for continuous verification. A record of what each agent did, and who triggered it, is what makes the other steps auditable instead of aspirational.

None of these steps require ripping out existing security tools. They require pointing the access discipline already applied to employees at the agents now running alongside them.

Zero Trust Was Always About the Data

The language around AI security changes every quarter. The underlying question does not: who, or what, is touching sensitive data right now, and does it have more access than it needs. Zero trust answered that question for human users for two decades. It answers it for AI agents the same way, provided the verification follows the data instead of stopping at the network edge.

Forcepoint's approach to AI security starts from that same data-first position. Classify first, enforce least privilege everywhere data moves and keep every agent's access scoped, brokered and logged. The companies that get this right now will not be rebuilding their security model when the next wave of autonomous AI arrives. They will be extending one that already works, the same way they extended it from the network to the cloud, and from the cloud to the endpoint.

Agents are just the newest identity zero trust has to account for. They won't be the last.