The Agentic Insider: Zero Trust Design for AI Agents That Act on Human Authority

When an AI agent leaks a shared drive, the audit log names an employee, not the agent. That single gap explains why identity systems built for people struggle with autonomous software.

The fix is not a better prompt. It is a set of architectural changes that limit what any one agent can reach, how long it can reach it, and where it can run.

What an Agentic Insider Is

An agentic insider is a non-human actor operating inside the organization's trust boundary on human authority. It is not a person and it is not malware. It is a delegation of access rights to an autonomous workflow.

The numbers show how fast this population has grown. One report puts the ratio of machine identities to human identities at 109:1, with 79 of those 109 classified as AI agents. Visibility has not kept up: only 47.1 percent of deployed agents are actively monitored or secured. A separate Cloud Security Alliance and Aembit survey found that 68 percent of organizations cannot tell human activity from AI agent activity in their logs.

Agentic insiders come in more than one form, and each needs different controls.

Most teams meet their first agentic insider by accident rather than through malice. A capable employee delegates more access than they realized to a tool that works faster and wider than anyone expected.

Why Human-Based IAM Fails for Agents

Traditional security models assume an authenticated person is operating a deterministic application. An agent breaks both halves of that assumption. It runs on a language model's non-deterministic reasoning, it moves at machine speed, and untrusted data it reads can steer it.

Consider the usual delegation. An employee gives an agent access to a mailbox, a code repository and cloud storage to summarize project status. If a malicious instruction hidden in a PDF triggers a mass data export, the logs record the employee as the actor. Delegation is the thing that identity models, data controls and case management systems were never built to represent.

The attacker's view is just as uncomfortable. Someone who hijacks an agent's intent, often through indirect prompt injection hidden in resumes, emails or web pages, gets legitimate access. The compromised agent presents valid credentials and calls expected APIs, yet acts entirely outside its assigned task. A login check at the start of a session will never catch that.

The money is real too. IBM and Practical DevSecOps put the average cost of an AI-related breach in 2026 at $4.88 million, and breaches involving unmanaged shadow AI cost an average of $670,000 more. The same source says 85 percent of enterprise breaches now involve compromised service or machine accounts, and it cites a Gartner prediction that by 2028, 25 percent of enterprise breaches will trace to AI agent abuse. On the regulatory side, the report notes that the EU AI Act's Article 15 requirements on robustness and cybersecurity for high-risk systems became fully enforceable in August 2026.

These gaps also show up when organizations try to modernize older systems or wrap legacy workflows in agents. Without rethinking identity and access, modernization costs climb as teams bolt on controls after the fact instead of designing for agentic access from the start.

Principle One: Keep Authority Outside the Model

The biggest shift is separating intelligence from authority. The controls over what an agent can access, which APIs it can call and whether its runtime persists must sit outside the model. A policy that lives only in a system prompt can be bypassed by hallucination or injection.

In practice, you wrap the non-deterministic part (the model and its orchestration) in deterministic parts: the operating system kernel, the identity provider and the network gateway. Enforcement then happens at the model gateway and at each tool call, not only at login or the network edge.

Federal guidance points the same way. Joint NSA, CISA and NIST guidance from October 2026 says to limit agents to the data, tools and systems their immediate tasks require, use strict network allowlists, and run monitored gateways to block unauthorized outside contact and hidden persistence. NIST had already launched its AI Agent Standards Initiative earlier in 2026 to formalize how agents authenticate, authorize and interoperate. Treating agents as generic service accounts with long-lived API keys is, in the words of one source, over.

For many enterprises, this also means revisiting how they run infrastructure and deployments. Teams that already have strong DevOps pipelines and automated enforcement find it easier to plug agent controls into the same gates instead of relying on ad hoc scripts or manual approvals.

Principle Two: Agents Request Credentials, They Do Not Hold Them

Standing access is what turns one hijacked agent into a large incident. Keys or tokens embedded in an agent's environment or code repository create a permanent blast radius. The alternative is to move from "agents hold credentials" to "agents request credentials".

Under that model, an agent asks a secrets manager for access to a specific resource and operation. It gets back a short-lived token, typically with a time-to-live of 5 to 15 minutes. If the agent's intent is hijacked, the window for lateral movement is small.

What Task-Scoped Identity Looks Like in Practice

Microsoft's Entra Agent ID is one concrete implementation of these ideas. Its design shows what to ask of any identity platform:

• A distinct identity per agent. Each agent has its own durable identity, separate from the user who launched it and the developers who built it. That lets security teams attribute actions and track ownership without confusing agent activity with human activity.
• Zero access by default. Agents start with none. A task grants only the authority that operation needs, for as long as it needs it.
• A ceiling set by the sponsor. Organization-wide policy stops an agent from obtaining authority its human sponsor does not have. Permissions shrink or expire as the task ends or the context changes.
• No tenant-wide admin rights. The system structurally bars agents from sensitive privileges such as deleting users or changing conditional access policies, and neither users nor administrators can override that baseline.
• Approvals that do not need MFA. Agents cannot answer MFA prompts or push notifications. For consequential actions, protocols such as Client-Initiated Backchannel Authentication route the approval request to the human sponsor's device before the agent's token receives the scope.

Under the hood, the on-behalf-of flow involves three actors: the user, an agent identity blueprint (the class definition) and the agent identity (the running instance). The blueprint authenticates with its own credentials and declares which instance it is acting as through an fmi_path parameter. The result is a narrowly scoped downstream token. The agent instance never holds long-lived standing credentials, and each action traces back to both the human and the instance.

Do Not Let Tool Servers Grant Their Own Access

The Model Context Protocol (MCP) connects AI clients to enterprise tools, and left unmanaged it creates a large attack surface. Unsecured MCP servers bring credential sprawl, incomplete audit trails and no view of what sensitive data enters the model's context.

The recommended pattern is that MCP servers never act as their own authorization servers. They delegate authentication and authorization to an external identity provider. The MCP client is the OAuth client, the MCP server is the resource server and the identity provider issues the tokens, so every tool call is authenticated, logged and subject to Conditional Access.

When MCP is wired this way, it also becomes easier to plug agents into a broader enterprise application architecture instead of treating each agent as a one-off integration with its own keys and rules.

Principle Three: Isolate the Agent Runtime

Identity controls decide what an agent may reach remotely. Runtime isolation decides where its code actually runs. Agents generate and execute untrusted code, touch local filesystems and make outbound network calls, so running them unmanaged on the host is a hazard.

Microsoft Execution Containers (MXC), which reached general availability in October 2026, are a cross-platform containment layer that sets OS-enforced boundaries around AI workloads. The design lesson is more important than the product: the policy governing an agent must sit outside the agent's control. A coding agent updating a website needs its repository and toolchain. It should not read personal documents, reach keys in other directories or change production server configuration.

The reason is plain. An agent that has drifted, or has read an injected instruction in something like a GitHub issue, could decide that rewriting host configuration or opening a reverse shell is the quickest way to finish its task. MXC intercepts filesystem, network and process requests at the kernel level so model output, tool calls and plugins cannot raise their own permissions.

Choosing a Containment Strength

MXC offers several backends, which shows the trade-off you will face with any sandbox.

Lightweight process containers start almost instantly but share the host kernel. MicroVMs give hardware-level defense in depth but add startup overhead and resource use that can slow high-frequency, multi-agent pipelines.

Default-Deny Is Safe and Annoying

MXC is configured through a declarative JSON schema covering read-only and read-write paths, inbound and outbound network rules, and process execution rights. It is default-deny: anything not explicitly allowed is silently blocked.

That is the right posture, and it creates friction. Models hallucinate paths and reach for unexpected tools or endpoints, so teams must profile agent workflows to map their real dependencies. MXC offers a learning mode that blocks access and records the denial in a structured JSON report, and a permissive (audit) mode that allows access but logs it. Analysts stress that audit mode must never be used for untrusted workloads in live production, because it disables the enforcement boundary.

Teams that already run agents inside Docker and Kubernetes-based environments can often layer MXC-style controls on top of existing container policies, using the same CI/CD flows to roll out and test sandbox rules.

Principle Four: Log Every Action and Score Risk Continuously

Scoped identity and a sandbox are structural. You also need to see what agents do. The practical minimum is full, immutable logging of each tool call, capturing the agent's distinct identity, the parameters passed and the data returned. Without a distinct identity per agent, those logs cannot answer the question the first section raised.

Microsoft's Project Perception shows where this goes next. It replaces a one-time procurement risk score with "Dynamic Agent Risk," a continuously updated assessment for each agent. It pulls signals from identity logs, endpoint activity, cloud interactions, network flows, data access patterns and the agent's own outputs to spot when behavior diverges from the sponsor's intent or from policy. The reasoning is sound: agent behavior can drift with the data it reads, changes in the underlying model or injected prompts, so an old score proves little.

Graduated Responses Beat a Kill Switch

When risk rises, Project Perception applies what it calls Dynamic Conditional Access. The response grows with the risk instead of flipping between allow and deny.

The graduated approach matters for operations. A blunt kill switch on every statistical anomaly disrupts productive work and creates alert fatigue for SOC analysts. Keeping safe reads while blocking destructive writes lets teams contain a problem without halting automation.

What Is Proven and What Is Not

Treat the vendor's strongest claims as claims. Project Perception also uses "Guardian Agents" (red, blue and green teams that probe, investigate and remediate). According to the vendor's marketing materials, if an expense-processing agent reads suspicious instructions in a scanned receipt and tries to query an unrelated HR database, a Guardian Agent steps in, strips its approval permissions and writes a forensic summary. The vendor also says this compresses work that would take several specialists and hours.

Independent evidence is thin. Critics note that the vendor has published no independent results on false-positive rates, containment speed during live breaches, or enforcement reliability in non-native SaaS environments. Coverage is reported as strongest for agents on local Windows endpoints or built in the vendor's own ecosystem, and weaker for agents embedded in outside applications or home-grown orchestration frameworks.

Cost is part of the decision. The report says the full capability set is bundled in the Microsoft 365 E7 tier, priced at $99.00 per user per month when paid annually. For a large workforce, that is a major line item to justify.

What a Custom Software Partner Builds

Agentic security touches identity providers, operating systems, secrets managers, gateways and log pipelines. Out-of-the-box vendor configuration rarely covers all of it, which is why organizations turn to custom software partners. The report describes several pieces of work.

• Design before autonomy. Before any agent gets autonomy, the team designs the workflow, identity model, permission scopes, human approval points and audit traceability.
• Identity blueprints. Blueprints are templates that define the security posture and metadata for every agent instance of a type. Done up front, they keep credentials on the blueprint rather than hardcoded in instances, so thousands of agent identities do not become credential sprawl.
• MCP gateways. A partner builds proxies between agents and enterprise tools that route by session, handle the OAuth 2.1 token exchanges with the identity provider, and may use secondary models to strip malicious payloads from the context before they reach a database.
• Policy generation pipelines. Writing restrictive JSON policies by hand for non-deterministic agents is hard. Partners build CI/CD pipelines that exercise the agent in permissive mode in staging, collect the denied calls, then generate a least-privilege policy that is locked down in production.
• Secure orchestration code. Static analysis, strict input validation and output sanitization across the SDLC help keep a compromised reasoning engine from executing SQL injection or cross-site scripting.

Handing a critical function to a third party also makes vendor risk the CTO's job: the partner's technical expertise, financial stability and AI deployment record all need review.

Organizations that already lean on a dedicated engineering team or long-term service contracts often fold agentic security into that relationship, so the same people who build and run systems also harden and monitor the agents that sit on top.

Five Steps to Start This Quarter

1. Take inventory. You cannot govern what you cannot see. Find sanctioned and shadow agents, then give each a named human owner, a defined purpose and a distinct identity.
2. Remove standing credentials. Replace long-lived keys and hardcoded tokens with short-lived, task-scoped tokens from a secrets manager, expiring in roughly 5 to 15 minutes.
3. Put a gateway in front of tools. Do not let agents talk directly to backend tools or unauthenticated MCP servers. Use a proxy or policy layer, with the enterprise identity provider as the sole authorization server enforcing Conditional Access on every call.
4. Contain the runtime. Sandbox agents with OS-level containment and default-deny policies sized to the task. Refine them in permissive mode, then enforce them in production without relying on the model's self-regulation.
5. Log and respond in grades. Capture every tool call with identity, parameters and returned data. Feed that into risk scoring and set responses that step from revoking writes to human approval to full isolation when behavior leaves its baseline.

Conclusion

The agentic insider is a delegation problem. The agent borrows a person's authority, works faster than any person, and can be steered by the data it reads. The controls that hold up all sit outside the model: a distinct identity, zero default access, short-lived task-scoped credentials, a sandbox with default-deny policy, complete logs and graduated responses.

None of this ships ready to run. The report points to the default-deny policies, MCP gateways and blueprint design as engineering work specific to each organization's systems, which is why it stresses working closely with custom software partners to map agent dependencies and build the policies.

Done well, this work also lays the foundation for safer AI in other parts of the stack, from integrating AI into existing systems to building new AI-powered applications that respect identity boundaries from day one.

FAQ

What is an agentic insider?

It is a non-human actor that operates inside the organization's trust boundary on human authority. It is neither a person nor traditional malware, but a delegation of access rights to an autonomous workflow.

Why can't traditional IAM handle AI agents?

It assumes a person operating deterministic software. When an agent acts on an employee's delegated access, logs record the employee as the actor, and delegation is something these systems were never built to represent. Agents also cannot answer interactive MFA prompts.

How do task-scoped permissions limit the blast radius?

Agents start with zero access and receive only the authority a specific task needs, for as long as it needs it. Short-lived tokens, typically 5 to 15 minutes, shrink the window an attacker can use if the agent's intent is hijacked.

What does an execution container add that identity controls do not?

It enforces a boundary on the machine itself. MXC intercepts filesystem, network and process requests at the OS kernel level, so model output and plugins cannot raise their own permissions.

Is audit or permissive mode safe in production?

No, not for untrusted workloads. Analysts stress that it disables the physical enforcement boundary. It is meant for learning and baseline policy creation.

Is Project Perception proven?

Not independently. The vendor describes how its protections should work, but critics note there are no published independent results on false positives, containment speed or enforcement in non-native SaaS environments.

Supporting Links

• The ultimate guide to the agentic insider
• Zero trust for AI agents: the 2026 enterprise security reset
• AI agent access and security use cases
• Cloud Security Alliance research on zero trust for agentic AI
• Walkthrough of Execution Containers and default-deny policy
• Microsoft's new controls for rogue AI agents

About Baytech

At Baytech Consulting, we specialize in guiding businesses through this process, helping you build scalable, efficient, and high-performing software that evolves with your needs. Our MVP first approach helps our clients minimize upfront costs and maximize ROI. Ready to take the next step in your software development journey? Contact us today to learn how we can help you achieve your goals with a phased development approach.

About the Author

Bryan Reynolds is an accomplished technology executive with more than 25 years of experience leading innovation in the software industry. As the CEO and founder of Baytech Consulting, he has built a reputation for delivering custom software solutions that help businesses streamline operations, enhance customer experiences, and drive growth.

Bryan’s expertise spans custom software development, cloud infrastructure, artificial intelligence, and strategic business consulting, making him a trusted advisor and thought leader across a wide range of industries.