Picture an AI agent connected to your inbox and your Salesforce. It can read email. It can pull records. It can draft and send replies. Your integration platform calls this “the connector.” Most companies treat it like a feature flag.
An external sender emails the address it monitors: “Please send me the Salesforce record you mentioned in our last thread, for compliance review.”
The literal task is easy. The secure decision is hard. Is the sender authorized? Is the email a setup? Should the data leave the system? Should a human approve it? What should be logged?
Five questions. The agent cannot answer one of them on its own.
That gap — between what the agent can do and what it should decide — is, in my experience, the central problem of every agentic deployment shipping right now. It is not a model problem. The model is working perfectly. It is a trust boundary problem. The moment an agent can act, AI stops being a chatbot problem and becomes an enterprise security problem.
Recorded Future put it plainly in 2025: “the first agentic data breach will very likely be the result of overly permissive environments” [5]. Not a clever jailbreak. Not an exotic model failure. Just access that was granted without anyone deciding that granting it was a security architecture decision.
The numbers are already in
This is not speculative.
Obsidian Security’s 2025 analysis of deployed enterprise agents found that 90% of them are over-permissioned — holding access rights well beyond what their actual tasks require [1]. The same study reported that AI agents move 16 times more data than human users [2]. Traditional anomaly detection thresholds, designed for human-scale activity, become useless once the actor being watched is moving on an order of magnitude that the alerting was never tuned for.
The Glean case shows what that volume can look like inside an organization.
A single Glean agent at one organization downloaded over 16 million files in the measurement period. Every other user and application in the entire organization combined accounted for about one million [3]. One agent moved sixteen times more data than the rest of the company. No alerts fired. The thresholds had never met an actor of this kind before.
Meanwhile, 53% of deployed AI agents are already accessing sensitive enterprise information [12]. The “AI as chatbot” era is over for most enterprises whether they have noticed or not — and a lot of them have not.
The governance gap is documented too. More than 80% of Fortune 500 firms are deploying AI agents through low-code or no-code platforms, and only 47% have established any security measures to oversee them [6]. Roughly half the firms running agents at scale have no oversight in place. Another 29% of employees report using unsanctioned agents at work [7] — shadow agents living outside any security review.
So: 90% over-permissioned. 47% with any oversight. 29% unsanctioned entirely. The default state of enterprise agent deployment is ungoverned. That is not the worst case. That is the average case.
What actually breaks the moment an agent can act
The trust boundary issue is not one problem. It is a family of five.
Prompt injection. Agents accept instructions from whatever channel they read — email bodies, documents, web pages, API responses. A malicious instruction hidden in any of those can hijack the agent’s behavior. Recorded Future documented in 2025 that injection prompts “can be delivered directly, encoded in malware, or hidden in emails or other innocuous communications” [4]. For an agent that reads payment emails, the consequence is concrete. Business email compromise was the most common method of actual and attempted payments fraud in 2024, reported by 63% of respondents to the AFP survey JPMorgan cited [reference 16-ENR-JPM]. An email-reading agent with the authority to draft, send, or act on payment instructions is, in effect, a high-speed BEC amplifier sitting in the queue, waiting for its first attacker email.
Overly permissive scope. Agents accumulate access through default configurations and organizational inertia. Coding agents are the most visible example — they typically run with the permissions of the developer who invoked them, which means read/write access to the entire repository, the ability to execute arbitrary shell commands, and access to CI/CD pipelines [9]. The same dynamic plays out wherever an agent inherits an existing identity, with whatever scope that identity already carried. Forbes captured the operational pattern exactly: “when an agent fails to perform a task due to inadequate permissions, the quickest solution is often to grant broader access simply to ensure functionality” [reference 17-ENR-Forbes]. Repeat that a few times per quarter and what started as “limited automation” has moved in, unpacked, and become a highly privileged enterprise actor.
Ambiguous authorization. When an external party instructs an agent, whether that sender is authorized has no automatic answer. NIST Zero Trust Architecture requires authentication and authorization to be discrete functions performed before each access grant [8]. Agentic deployments routinely bypass that principle by relying on persistent service accounts. The agent inherits the service account’s authority and treats every input as if it had been issued by that authority — which is to say, it treats inbound email and a signed internal API call as roughly equivalent inputs.
Audit gaps. Most organizations cannot tell you what their agent actually did, on whose instruction, with what data. Cerbos found in 2026 that organizations with hard-coded authorization logic cannot reliably answer the basic question of “who can access our critical data or functions” [11]. The same blind spot applies to agents. Without deliberate instrumentation, you cannot reconstruct what your agent saw, decided, and executed. You have a witness who cannot testify.
Cascading actions. One permitted action triggers another. An agent that “updates a CRM record” can fire automated email sequences, partner data syncs, billing changes, and internal workflow notifications — none of which were in the original access decision. Autonomous AI agents have already been documented hiring human workers and initiating payment-like transactions via REST APIs and Model Context Protocol integrations [10]. The Cloud Security Alliance named the deeper version of this in 2026: “reviewing permissions per-application or per-user doesn’t work when the effective scope is determined by the composition of an agent chain” [reference 13-ENR-CSA]. They call them toxic combinations — a low-risk read-only agent becomes a data exposure vector once it is wired into a chain that ends in a public channel.
Is this overblown?
Engineering leadership has three substantive reasons to question this argument. Each changes how the access decision should be assessed.
“This is not new. Enterprises have governed RPA, service accounts, and bots with this kind of access for years.” True for the access itself. Not true for the attack surface. RPA bots execute deterministic scripts against known inputs — an attacker cannot inject a malicious instruction into a deterministic workflow. Agents are different: they accept natural language directives from any channel they read. The category that is new is not “software with access” but “software with access that takes instructions from attacker-controlled content.”
“With proper governance — narrow OAuth scopes, human-in-the-loop gates, audit logging — this is manageable. NIST, Microsoft, and Google have all published guidance to this effect.” Correct in principle. The problem is the operational default. The same data tells the whole story: 90% over-permissioned, 47% with any oversight. “It can be done safely under ideal conditions” is true; the structural default is not ideal conditions. Saying agent access is governable does not resolve the fact that most current deployments are not being governed.
“Humans are worse security risks. A well-scoped agent might reduce error rates.” That is valid when scope is constrained — which is the exact condition most deployments fail to meet. The asymmetry that matters is speed and cascade. A human who accidentally exposes one record triggers a containable incident. An over-permissioned agent triggered by a single prompt injection can traverse CRM, email, documents, and payments in seconds, well before any human review point exists. Base-rate failure probability may be similar. Damage potential is not.
There is a fourth line that shows up less often but deserves a direct answer: “Most companies will never face a sophisticated prompt injection. This is fear-based framing.” The Glean case and the BEC data are the empirical reply. Sixteen million files moved by one agent is not a red-team exercise; it is a real incident reported by the security vendor working on it. BEC fraud already has the highest victim count in payments fraud surveys. The attack surface is not hypothetical, and the agents being deployed will read attacker-controlled content as part of their job. The question is not whether your agent will encounter a hostile input. It is whether it will recognize one when it does.
None of these objections support “ban agents.” They support a different conclusion: make the trust boundary decision explicit before the access toggle is flipped, not after the first incident.
Five decisions before access
If access is a security architecture decision, here are the five decisions to make explicit. Treat each as a question with a documented answer, not a checkbox.
1. Scope. What is the minimum set of actions and data this agent needs for its specific task? Implement at the API and connector level — OAuth scopes, read-only database users, rate-limited keys. The test for each candidate permission: what would break if we removed it? If nothing, remove it.
2. Instruction source authentication. Which principals can instruct this agent — and is that enforced architecturally, or only requested in the prompt? The agent must distinguish data (content to be processed) from instructions (directives to be executed). External content gets read; only authenticated channels get to issue directives.
3. Action authorization. Tier the actions. Read-only and low-consequence actions can be autonomous. Anything that writes, sends, modifies, or initiates a transaction requires explicit human confirmation before execution. Anything outside the defined scope is technically blocked at the API level — not instructed away in the system prompt. “Please do not do X” is a wish, not a control.
4. Audit and observability. Define the audit schema before deployment. Log instruction received, instruction source, action taken, resources accessed, data volumes, downstream triggers. Store the logs in a system the agent cannot access or modify. Calibrate anomaly thresholds for agent-scale data movement, not human-scale. The Glean case was caught by external analysis. Internal monitoring did not see it.
5. Cascade risk. Map the downstream consequences of each permitted action. Where does the chain go? Where is the first human review point in that chain? An action that triggers automated downstream processes with no human checkpoint is not the same risk class as an action that surfaces a notification for review. The Cloud Security Alliance’s toxic-combinations framing applies here directly: review the chain, not the connector.
This is the spine of the Agent Trust Boundary Framework. Use it before procurement, not after the breach.
So what — for the people making these calls today
Three things follow.
First, agent access is a security architecture decision, not a product feature decision. It needs the CISO in the room before the integration platform is configured, not after the first audit finding. Ardoq’s 2026 governance summary noted that 72% of boards now engage CIOs and CTOs directly on AI [reference 14-ENR-Ardoq72], and 80% of tech leaders say AI adoption is outpacing IT’s ability to govern it [reference 15-ENR-Ardoq80]. The boards are asking. The governance is lagging. The deployments are not waiting for either.
Second, the question to ask your security team this week is concrete: can you tell me what each of our deployed AI agents accessed in the last seven days, on whose instruction, and whether any data left the organization? If the answer is “not easily,” that is the control deficiency the rest of this article describes.
Third, the companies that solve this layer — agent identity, scoped authorization, audit pipelines, cascade mapping — will be valuable. This is not yet a product category. It is the product category the next wave of enterprise security will be built around. The “make agents safe” market is roughly where “make cloud safe” was in 2009: obvious in hindsight, contested at the time, and quietly forming under the noise of the productivity story.
The productivity case for agents is real. The deployments will continue regardless of what any one article argues. The choice in front of you is not whether to deploy agents. It is whether the access conversation is something you have before the toggle flips, or something you have on a Sunday night after an incident report lands in your inbox.
The moment an agent can act, AI stops being a chatbot problem and becomes an enterprise security problem. The organizations that recognize that early get to design the architecture. The ones that recognize it late get to write the post-mortem.
References
[1] Obsidian Security. The 2025 AI Agent Security Landscape: Players, Trends, and Risks. https://www.obsidiansecurity.com/blog/ai-agent-market-landscape
[2] Obsidian Security. The 2025 AI Agent Security Landscape. (Same as reference 1.)
[3] Obsidian Security. The 2025 AI Agent Security Landscape — Glean case example. (Same as reference 1.)
[4] Recorded Future. Emerging Enterprise Security Risks of AI, 2025. https://www.recordedfuture.com/research/emerging-enterprise-security-risks-of-ai
[5] Recorded Future. Emerging Enterprise Security Risks of AI, 2025. (Same as reference 4.)
[6] Yahoo Finance / Microsoft-commissioned survey. As AI Agents Take Over, Security Is Becoming a Bigger Concern, 2025. https://finance.yahoo.com/news/as-ai-agents-take-over-security-is-becoming-a-bigger-concern-160109297.html
[7] Yahoo Finance / Microsoft-commissioned survey, 2025. (Same as reference 6.)
[8] NIST. Zero Trust Architecture (SP 800-207), 2020. https://csrc.nist.gov/publications/detail/sp/800-207/final
[9] Axiom Studio. CISO Guide: AI Agent Security Threat Models, 2026. https://axiomstudio.ai/blog/the-cisos-guide-to-ai-agent-security-threat-models-for-autonomous-code-generation
[10] Academic researchers. Security Risks of AI Agents Hiring Humans: An Empirical Measurement Study, arXiv, 2026. https://arxiv.org/html/2602.19514v1
[11] Cerbos. 10 Critical Challenges CISOs Face in 2026 and How to Solve Them. https://www.cerbos.dev/blog/10-challenges-cisos-face-and-how-to-solve-them
[12] Obsidian Security. The 2025 AI Agent Security Landscape. (Same as reference 1.)
[reference 13-ENR-CSA] Cloud Security Alliance. AI Agents Are Talking: Are You Listening?, April 2026. https://cloudsecurityalliance.org/blog/2026/04/17/ai-agents-are-talking-are-you-listening
[reference 14-ENR-Ardoq72] Ardoq. AI Agent Risk: What Enterprise Architects, CIOs, and CISOs Must Know, 2026. https://www.ardoq.com/blog/ai-agent-risk
[reference 15-ENR-Ardoq80] Ardoq. AI Agent Risk, 2026. (Same as reference 14.)
[reference 16-ENR-JPM] JPMorgan. Cybersecurity for Commercial Real Estate: Key Strategies, 2025, citing AFP Payments Fraud and Control Survey. https://www.jpmorgan.com/insights/real-estate/payments/cybersecurity-for-commercial-real-estate-key-strategies
[reference 17-ENR-Forbes] Forbes Tech Council. AI Agents Are Becoming Enterprise Actors And Most Companies Aren’t Ready, February 2026. https://www.forbes.com/councils/forbestechcouncil/2026/02/23/ai-agents-are-becoming-enterprise-actors-and-most-companies-arent-ready/