Zero Trust Access for People and AI Agents

Consider a development workflow in which an employee signs in from a managed laptop and launches a coding agent. The employee's authentication is valid. The device meets company policy. The agent then reads project files and uses a connected tool to send information to an external service.

This is an illustrative scenario, but the control question is concrete: which policy governs the agent's next action?

Cisco/Duo's Anatomy of a Modern Phishing Attack emphasizes device inventory, device trust, adaptive access and monitoring as defenses against account compromise. Those principles remain relevant. Applying them to AI-enabled work requires extending the inventory and the access model to the software acting with an employee's or workload's permissions. [1]

Device trust is one input to an access decision

A trusted device provides useful evidence about the environment requesting access. It does not establish that every process on that device needs every resource available to the employee.

NIST's zero trust model focuses on protecting resources and evaluates authentication and authorization separately. It does not grant implicit trust merely because an account or asset is inside the network or owned by the organization. [2]

For AI-enabled workflows, the practical implication is to examine the full path from the initiating person to the resource and the resulting action. OWASP's agent security guidance identifies risks involving excessive tool permissions, prompt injection and sensitive data exposure through tools and APIs. [3]

The objective is to give legitimate agents a useful, bounded role in the business.

Identify how each agent obtains access

An agent may act on behalf of a signed-in person, authenticate with its own workload identity or use a dedicated account supported by a platform. Those patterns affect where access policies apply.

Microsoft's documentation for Conditional Access for agents distinguishes delegated, application-only and agent-user access. A policy aimed at one identity type does not automatically cover the others. Available enforcement also depends on the supported access pattern and licensing. [4]

This makes identity mapping a necessary step before selecting controls.

These are assessment prompts. The right implementation depends on the application, identity provider and runtime.

Build an inventory that explains permissions

Start with one team and record the agents it uses, the endpoints or runtimes hosting them, the identities involved and the business purpose.

For each workflow, identify the folders and repositories it can read, the tools it can invoke, the external destinations it can reach and the operations that require approval. Include Model Context Protocol (MCP) servers and other connectors in the review.

OWASP's development guidance recommends giving agents attributable identities where possible and using scoped, short-lived credentials. It also highlights the risk of exposing production secrets through an agent's environment or configuration. [5]

An inventory becomes useful when it supports a decision. If nobody can explain why an agent needs a permission, record it as an unresolved access requirement with an owner.

Put boundaries around execution

Use distinct controls for the environment and for the work performed inside it.

Device or runtime checks can establish whether the environment meets the requirements for a sensitive workflow. Tool authorization must then constrain which resources and operations the agent can use.

A practical permission design separates reading from writing and distinguishes preparing an action from executing it. An agent that summarizes a repository may need source files and test tools; it does not automatically need production credentials or permission to publish a release.

OWASP's guidance on excessive agency recommends restricting tools and their permissions, requiring approval for high-impact actions and enforcing authorization in downstream systems. [6] Apply those decisions in the tool, API or execution environment rather than relying solely on instructions written into a prompt.

Isolation can add another boundary. OWASP's development guidance recommends understanding the scope of an agent's sandbox and considering disposable environments without production credentials. A container or sandbox needs explicit filesystem and network restrictions to provide the intended protection. [5]

Connect visibility to a response

Authentication logs explain part of an agent workflow. Responders also need evidence of what the agent attempted and what the tool permitted.

Where the platform provides it, connect the initiating user, agent identity, session, requested operation, target resource, policy decision and outcome. OWASP recommends structured records for sensitive actions, including approval and policy information. [3]

Define a response procedure alongside the logging requirements. Identify who can stop the runtime, disable new access and terminate applicable sessions. Microsoft's documentation notes that Conditional Access evaluates token issuance or refresh, with continuous evaluation supported for certain events and resources. A policy change should therefore be tested against the actual access path rather than assumed to stop every existing operation immediately. [4]

Avoid placing secret values in those logs. Capture the evidence needed to investigate while protecting the underlying data. [5]

Pilot one workflow and test its boundaries

Choose a real workflow with an owner and a clear business outcome. Agree on the permitted data, tools and actions before enabling broader access.

Using test accounts and non-sensitive data, check whether the controls can:

• Block access to a folder outside the approved scope.
• Deny an unapproved tool or external destination.
• Require authorization for a change beyond the agent's assigned task.
• Record the initiating identity and the final enforcement result.
• Stop further execution after the responsible team initiates containment.

These checks are a proposed acceptance plan, not a claim that every platform supports each control. Record unsupported requirements and decide whether another enforcement layer, a narrower scope or a different workflow is needed.

For security teams and the partners supporting them, the deliverable is a workflow with explainable permissions, tested boundaries and an accountable owner. That gives the business evidence it can use when deciding where to expand AI adoption.

Planning an access or endpoint security project for AI-enabled workflows? Share the workflow, affected systems and target timeline with sni@telekomplex.net. Connect with Telekomplex at telekomplex.net.

Sources

1. Cisco/Duo Security. Anatomy of a Modern Phishing Attack. 2021.
2. NIST. SP 800-207 Zero Trust Architecture. August 2020.
3. OWASP. AI Agent Security Cheat Sheet.
4. Microsoft Learn. Conditional Access for agents.
5. OWASP. AI Agent and MCP Security — DevSecOps Guideline.
6. OWASP. LLM06:2025 Excessive Agency.