AI Agent Enterprise Security Threat Model: A 5-Tier Access Framework
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
GitHub Copilot, Microsoft 365 Copilot, Claude in development tools, Cursor, and Zapier AI are not chatbots. When configured with workspace access, these tools are autonomous agents that call external APIs, write and execute code, read and write documents, query databases, and in some configurations spawn sub-agents to complete delegated tasks. They authenticate to your systems using identity credentials. They access your data under the permissions of the user who authorized them. And in most enterprises today, they are deploying without a threat model, without logging requirements, and without a defined approval process. This guide gives you a 5-tier access framework for AI agents, threat scenarios for each tier, detection logic, and a governance checklist to complete before wide deployment.
Why AI Agents Are Different from Traditional Service Accounts
Traditional service accounts have defined, static permission sets and execute predetermined operations. An AI agent is different in three fundamental ways that change the threat model entirely.
Autonomy and Dynamic Decision-Making
A service account executes a script. An AI agent decides which actions to take based on its interpretation of a goal. This means an agent may take actions that were not explicitly anticipated by the person who authorized it. The blast radius of a compromised or misdirected agent is not bounded by a predefined action list. It is bounded only by the permissions the agent holds.
Dynamic Permission Acquisition
Some agentic frameworks allow agents to request additional permissions at runtime to complete a task. An agent tasked with 'set up a new project environment' may request write access to cloud infrastructure, create new IAM roles, and invite external users to collaboration tools. Each step may be individually reasonable. The cumulative permission surface after task completion may be far broader than intended.
Prompt Injection Attack Surface
Unlike a service account that executes code, an AI agent processes natural language from its environment. A malicious instruction embedded in a document the agent reads, an email it processes, or a web page it visits can redirect the agent's behavior. This is prompt injection. It is not hypothetical. Documented proof-of-concept attacks against M365 Copilot, GitHub Copilot, and several autonomous agent frameworks already exist in 2025.
The 5-Tier Access Model for Enterprise AI Agents
Not all AI agents are equal in their risk profile. The 5-tier model classifies agents by the most powerful action category in their permission set. An agent in Tier 3 that can also read documents is still a Tier 3 agent. Classification is always by the highest-capability tier, not the most common operation.
Tier 1: Read-Only Document Access
The agent can read documents, emails, calendar entries, and knowledge base content. It cannot write, delete, or take external actions. Examples: a summarization agent, a document Q&A agent with no write permissions. Blast radius: information disclosure. Threat scenario: the agent reads a document containing a prompt injection instruction that causes it to exfiltrate content to an attacker-controlled summary destination. Controls: restrict the agent's output channels. Log all documents accessed and all outputs generated.
Tier 2: Write Access to Business Systems
The agent can create or modify records in ticketing systems, CRM, project management tools, calendars, or email. It cannot execute code or make arbitrary external API calls. Examples: a Copilot agent that can create Jira tickets and send emails. Blast radius: data integrity corruption, unauthorized communications on behalf of users, social engineering amplification. Threat scenario: prompt injection via an incoming email causes the agent to send fraudulent approval messages to financial systems. Controls: require human confirmation for outbound communications above a defined threshold, log all write operations with the triggering context.
Tier 3: Code Execution
The agent can write and execute code, run scripts, or interact with shell environments. Examples: Cursor, GitHub Copilot workspace agents with terminal access, code-execution-enabled AI development tools. Blast radius: full compromise of the development environment, introduction of malicious code into repositories, lateral movement via code execution context. Threat scenario: a malicious dependency documentation page contains a prompt injection that causes the agent to insert a backdoor into the codebase it is building. Controls: sandbox code execution environments, require human review for all repository commits, log all executed commands with the agent session that triggered them.
Tier 4: External API Calls
The agent can make arbitrary calls to external APIs, including third-party services, cloud providers, and web endpoints. Examples: Zapier AI with broad connector access, custom agents with HTTP tool access. Blast radius: data exfiltration to external destinations, unauthorized account actions in connected SaaS platforms, credential exposure through API calls to attacker-controlled endpoints. Threat scenario: prompt injection causes the agent to POST sensitive internal data to an external endpoint disguised as a legitimate API. Controls: allowlist permitted external domains, require TLS certificate validation, log all external calls with request payloads where legally permissible.
Tier 5: Sub-Agent Spawning
The agent can create, direct, and delegate tasks to other agents. Examples: multi-agent orchestration frameworks where a coordinator agent spawns specialized sub-agents. Blast radius: exponential permission amplification if sub-agents inherit or expand on the parent agent's permissions, cascading actions across multiple systems before any human review point. Threat scenario: a prompt injection in a coordinator agent causes it to spawn a sub-agent with code execution and external API permissions to complete a 'cleanup task' that exfiltrates and deletes data. Controls: sub-agents must inherit a permission set no broader than the parent, all sub-agent spawning events must generate a distinct audit log entry, implement a maximum sub-agent depth limit.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Prompt Injection: The Attack Vector Your SOC Is Not Watching
Prompt injection is to AI agents what SQL injection was to web applications in 2005. The attack is conceptually simple, the defenses are immature, and most organizations have no detection for it. OWASP rates prompt injection as the number one risk in the LLM Top 10.
How Prompt Injection Works Against Enterprise Agents
An attacker places a natural language instruction in a location the agent will process. This could be a malicious comment in a public GitHub repository the agent is summarizing, an invisible-text instruction in a shared document, a crafted email subject line, or a web page the agent visits as part of a research task. When the agent processes this content, it may interpret the injected instruction as a legitimate user request and execute it.
Documented Enterprise Attack Scenarios
Researchers demonstrated in 2025 that M365 Copilot could be directed via injected instructions in a shared Word document to search the user's email for sensitive keywords and include the results in its next response. GitHub Copilot workspace agents have been shown susceptible to instructions embedded in README files and code comments that redirect the agent's code generation behavior.
Detection Logic for Prompt Injection Attempts
Build detection for three signals: agent actions that were not initiated by a direct user request (the agent takes an action without a corresponding user message in the session log), agent outputs that reference content from documents not in the user's stated task scope, and agent attempts to access systems or data that have no relationship to the user's stated task. None of these are definitive indicators on their own, but their combination is highly anomalous.
Logging Requirements Per Tier
Logging AI agent actions is not optional if you want any chance of detecting abuse or reconstructing what happened during an incident. The logging requirements increase with tier because the blast radius increases with tier.
Tier 1 and Tier 2 Logging Baseline
At minimum: log the user identity that authorized the agent session, the start and end time of each session, all documents or records accessed (by ID, not content), all write operations with the target object and the change summary, and all outputs delivered to the user. Retain for 90 days at minimum.
Tier 3 Code Execution Logging
In addition to the Tier 1/2 baseline: log every command executed with the full command string, the working directory, and the exit code. Log all files created, modified, or deleted by the agent. Log all repository commits attributed to agent sessions with a distinct identity tag so they are distinguishable from human commits in audit trails. Retain for 180 days.
Tier 4 and Tier 5 Enhanced Logging
In addition to all lower-tier logging: log all external API calls including the destination domain, HTTP method, and response status code. For Tier 5, log every sub-agent spawning event with the permissions granted to the sub-agent and the delegating parent agent's identity. Retain for 1 year. These logs are potential incident response evidence and should be stored in a tamper-evident system.
Detection Rules for AI Agent Abuse
Security teams need detection logic specific to AI agent behavior. Generic DLP and network monitoring rules were not designed for the action patterns of agentic systems. These detection rules address the most likely abuse scenarios per tier.
Anomalous Data Access Volume (All Tiers)
Alert when a single agent session accesses more than N documents or records within a defined time window, where N is significantly above the baseline for that agent type and user. A summarization agent reading 5 documents in a session is normal. The same agent reading 500 documents in 10 minutes is an anomaly worth investigating regardless of whether the cause is prompt injection or a misconfigured task.
Outbound Data to Unexpected Destinations (Tier 4+)
Alert when an agent makes an outbound API call to a domain that is not on the approved external endpoint allowlist, or when the volume of data in an outbound call significantly exceeds the volume of data in the user's stated task input. An agent tasked with 'check the weather' that sends 50KB of data outbound is exhibiting anomalous behavior.
Permission Escalation During Session (All Tiers)
Alert when an agent acquires permissions during a session that were not part of its initial authorization. Dynamic permission acquisition is a feature in some agentic frameworks. From a security perspective, it is an alert-worthy event that should require human confirmation before the permission is granted.
Sub-Agent Chain Depth Exceeding Threshold (Tier 5)
Alert when a multi-agent chain reaches more than three levels of delegation. Legitimate multi-agent workflows rarely require more than two to three levels. A deep delegation chain that was not part of a user's stated task is a strong indicator of either a prompt injection attack or a misconfigured automation runaway.
Governance Checklist Before Wide Deployment
If an AI agent is being deployed to more than a handful of pilot users, the following governance steps should be completed before broad rollout. Each item maps to a specific risk that has been exploited in documented enterprise AI incidents.
Define the Agent's Tier Classification
Determine which of the five tiers applies to the agent based on its highest-capability action. Document this classification in the agent's configuration record. Any subsequent capability additions that change the tier classification must trigger a new security review.
Assign a Non-Human Identity with Least Privilege
Create a distinct identity for the agent rather than running it under a user's credentials. Scope that identity's permissions to the minimum required for the agent's defined task set. Review permissions quarterly. The agent identity should not have standing access to resources it only needs occasionally.
Document the Blast Radius for Each Tier
For each tier the agent operates in, write a one-paragraph description of what an attacker could accomplish with that agent's permissions. Have the CISO or security manager sign off on the documented blast radius before deployment. This step alone prevents the most common governance failure, which is deploying a high-tier agent without anyone having explicitly acknowledged what it could do in adversarial hands.
Configure Logging Before Launch
Logging must be configured and verified before the agent goes to production, not after. A common failure pattern is deploying an agent to production users while logging is 'on the backlog.' When an incident occurs, there is no record. Treat absence of logging as a deployment blocker for Tier 3 and above.
Establish Human Review Checkpoints
For Tier 3 and above agents, define explicit human review points in the agent's workflow where a person must confirm before the agent proceeds. These checkpoints should correspond to the highest-risk actions in the agent's capability set: before any external API call, before any code commit, before any communication sent on behalf of a user.
Test Prompt Injection Resistance Before Deployment
For agents that process external or user-generated content, include prompt injection testing in the pre-deployment security review. Attempt to redirect the agent's behavior via injected instructions in the document types it will process. Document the results. Agents that demonstrate susceptibility should be restricted from processing untrusted content until mitigations are in place.
The bottom line
The enterprises that get this right will be the ones that treated their first AI agent deployment as a forcing function to build the NHI security infrastructure they needed anyway. Distinct agent identities with least-privilege permissions. Logging at the action level. Detection rules tuned to agent behavior patterns. Human review checkpoints at high-risk action boundaries. These are not burdensome requirements. They are the same controls you would apply to any privileged service account that can execute code and make external API calls. The fact that the service account reasons in natural language does not change the underlying security model. Build the governance before the agents are in wide production. The window to do it right is closing fast.
Frequently asked questions
What makes AI agents a new category of non-human identity risk compared to traditional service accounts?
Traditional service accounts execute predetermined code with static permission sets. AI agents make autonomous decisions about which actions to take, can acquire permissions dynamically during task execution, and process natural language from their environment which creates a prompt injection attack surface. The blast radius of an AI agent is bounded by its permissions, not by a predefined script, which means the effective risk surface is significantly harder to scope than a conventional service account.
What is prompt injection and why does it matter for enterprise AI agents?
Prompt injection is an attack where malicious instructions are embedded in content that an AI agent processes. When the agent reads the content, it may interpret the injected instruction as a legitimate user request and execute it. Researchers have demonstrated successful prompt injection attacks against M365 Copilot, GitHub Copilot, and multiple autonomous agent frameworks using injected instructions in shared documents, emails, README files, and web pages.
How should AI agent identities be provisioned differently from human user accounts?
Each AI agent should have a distinct non-human identity separate from any user account. That identity should be scoped to the minimum permissions required for the agent's defined task set and reviewed quarterly for creep. Agent identities should be tagged distinctly in your IAM system so that their actions are identifiable in audit logs as agent actions rather than human actions. Never run an agent under a user's personal credentials.
Which tier requires the most security scrutiny before deployment?
Tier 5 (sub-agent spawning) has the highest blast radius because it can generate cascading actions across multiple systems through delegated agents before any human review point. However, Tier 3 (code execution) is the most commonly deployed high-risk tier in enterprise environments today, particularly through development tools like Cursor and GitHub Copilot workspace agents with terminal access. Tier 3 deployments should be treated as requiring full security review, not a lightweight pilot authorization.
What detection rule should a SOC prioritize first for AI agent monitoring?
Start with anomalous data access volume: alert when a single agent session accesses significantly more documents or records than the established baseline for that agent type within a defined time window. This catches both prompt injection attacks that redirect the agent to exfiltrate broadly and misconfigured agent tasks that are unintentionally over-reading. It requires only access logging, which should be in place before any agent goes to production.
Does this threat model apply to Microsoft 365 Copilot specifically?
Yes. M365 Copilot with standard configuration operates at Tier 2 (write access to business systems including email, Teams, and calendar). When configured with Power Automate integration or external connector access, it moves to Tier 4. Microsoft published guidance in 2025 acknowledging prompt injection risks in M365 Copilot and recommending sensitivity label controls to limit what content the agent can process. Organizations should apply least-privilege principles to M365 Copilot's data access scope in the admin center.
How should organizations handle AI agents that need to access sensitive data classified under DLP policies?
AI agents should be explicitly identified as a subject in your DLP policy configuration. Most DLP platforms now support service account identities in policy scope. Configure the agent's identity so that access to data above a defined sensitivity classification (e.g., Confidential or Highly Confidential) either requires explicit user confirmation at the time of access or is blocked entirely. Do not rely on the human user's DLP context carrying over to the agent's actions.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.