Mark McLaughlin, Product Marketing Manager | Aurascape
September 8th, 2026 | 🕐 8 minute read

Introduction

In security, it pays to keep unearthing and testing assumptions.

This is especially important as agents begin to take actions with increasing responsibility and blast radius. Autonomous agents change what used to be fundamental facts of security: An approved application plus an authorized user is acceptable traffic. Every action traces back to a person. A permission, once reviewed, stays scoped. These assumptions held for the world the tools were built in, and the tools that enforce them still do that job well.

Agents change the unit of action: a person gives one instruction, and the agent turns it into a chain of activity. Read this system, call that tool, write to a connector. The controls in place check the destinations involved, but struggle to understand each interaction. Furthermore, identity is blurring: agents interact with and instruct one another, and traditional security struggles to trace the original prompt and authority back to a human identity. This lack of interaction-level understanding, combined with difficulty tracing identity and delegated authority, sum to a growing gap in control.

Here are six assumptions worth re-examining, what breaks each one, and steps you can take to keep control as agents proliferate.

Assumption 1: An approved app plus an authorized user equals acceptable traffic

This is the working assumption of destination-based security, and it continues to work for ordinary web and SaaS traffic. Even activity-level controls in a CASB act on destinations, identities, and data patterns. But what happens if the intention, or mode, within the AI tool changes?

Here is an example: In one session, a user asks the AI tool to summarize a document, then generate code, then the user makes a request which causes the tool to flip into agent mode and call tools. Same app, same login, multiple different modes and capabilities, each with a vastly different risk profile.

Questions to ask: Can our existing security tools distinguish when the intention within an authorized AI tool changes from chat to producing artifacts, to making tool calls, calling APIs, or browsing the web? Do our tools decode and understand prompts and responses? Can we set policy which allows use of the application, except with guardrails for certain intentions?

The replacement control works at the level Aurascape calls Intentions: the specific modes and capabilities inside an application, such as summarize, upload, generate code, or agent mode. Policy set on Intentions lets the organization keep the sanctioned tool running while governing the specific modes that carry risk or excessive cost. Allow the summaries and put rules on agent mode.

Assumption 2: Every action traces back to an accountable person

One authenticated session used to mean one human doing things. An agent converts one instruction into many calls, and the session log records the login, not what followed. When something goes wrong, “who did this, and were they allowed to?” has two bad answers: the human sponsor who typed one sentence, or a sub-agent spawned to handle one element of the task. Cloud Security Alliance research from 2026 found that 82% of organizations have AI agents in their environment they do not know about, and a separate CSA study on agent identity found only 28% of organizations can trace agent actions back to a human sponsor across all environments. 

Authentication does not settle this, because authentication confirms who connected. It says nothing about whether each tool call serves the task at hand. OWASP ranks Excessive Agency among the top risks for LLM applications for exactly this reason: agents often hold more capability than any single task needs. 

Questions to ask: Can we trace actions back to the agent with delegated authority? Can we identify and set policy for agents running locally? Can we monitor agents we build and run in platforms like AWS Bedrock AgentCore? 

What’s needed is tool-call level control for every interaction. Aurascape discovers and monitors agents, then enforces scoped permissions bound to them, evaluating each tool call against the authenticated user, the agent, the server, the tool, and the data involved. Each observed call is preserved in a decoded record naming the user, the application, the server, the tool, the parameters, the data or threat categories detected, and the policy action taken. The record of the interaction becomes specific: this user’s agent called this tool with this data, and here’s the policy that fired.

Assumption 3: A review at a point in time describes the risk

Access reviews, configuration reviews, and pre-launch testing share one shortcoming: they describe a moment. Agent workflows are dynamic things. Configurations change as teams add servers, connectors, and tools, often installed from a package registry like npm or cloned from a public repo. And a point-in-time review misses these additions, or catches them after actions have already been taken. A workflow’s behavior changes when its model or tools change, which can often happen when third-party MCP servers, tool descriptions, and resources are involved. And risk hides in sequences: an agent can read sensitive records through one server and write them out through a messaging platform connector, two individually permitted calls that add up to data walking out the door. 

Questions to ask: Do our controls watch agent activity continuously, or describe it at review time? When a workflow gains a new server, tool, or connector, what notices, and does it trigger policy action or a security review? Can we see a risky sequence across calls, or only judge each call alone? 

The right control runs continuously, at execution, for every AI interaction. For the agents teams build and run, Aurascape restricts access to an explicit list of approved servers and tools and watches the calls as they happen. Direction-aware classifiers inspect requests and results, so sensitive data and threats are caught wherever they appear, and cross-call lineage makes a risky sequence visible and blockable.

Assumption 4: Validated input is safe input

Traditional security checks who the user is and what they type, then trusts the content a system already holds. Even zero trust, which verifies every request, decides only who may reach content. It does not ask what the content says, because plain language was not something a system would execute. Scanners hunt for malicious code, and a prompt injection carries none. AI agents changed the rule: a sentence in a document is now an instruction an agent may act on. Attacks arrive inside the content the agent reads, not the text the user types: a shared document, a web page, an email, a tool result. This is prompt injection. 

To a model, everything it reads is just text. CVE-2025-32711, the EchoLeak vulnerability reported in Microsoft 365 Copilot in 2025, proved the point with zero clicks: a crafted email sat in the inbox until Copilot retrieved it as context for an innocent question, and the instructions hidden inside it did the rest.

Questions to ask: Can our security controls inspect all the data AI tools interact with, regardless of its origin? Can we reliably detect a threat that arrives inside an AI interaction? 

The control that works here inspects what the agent consumes, not only what the user types. Aurascape inspects prompts, responses, and tool results for prompt injection, jailbreaks, and tool poisoning before the agent acts. It also pins tool definitions at sanctioning time, because a tool’s description is itself text the model reads; a changed definition requires an explicit re-fetch and review before it takes effect.

Assumption 5: Data controls at access time cover the data

File permissions and upload controls govern the moments a person opens or moves a file. Agents move data mid-execution, in forms that are not files: prompt text, code snippets, tool parameters, connector responses, generated summaries. Data even moves between sessions. For example, two Claude Code sessions working in different repos can message each other, and one can prompt the other to pull, commit, or push, when permissions allow. 

Inline DLP behind a decrypting proxy pattern-matches the HTTP bodies it can read. But agent traffic also rides WebSockets, Protobuf, gRPC, and QUIC, where traditional security engines are often blind. This is especially true of AI coding assistant traffic, where long-lived sessions run on these protocols. Traditional security often struggles to inspect these interactions without breaking streaming, forcing teams to decide between securing the coding session or keeping developers in flow. 

Questions to ask: Can our existing security tools inspect and consistently govern long-lived AI sessions without breaking user experience? Can our tools inspect and apply data and threat policy to multimodal data in prompts and responses? 

Proper controls inspect traffic inside the exchange itself, for entire conversations and sessions. Aurascape applies 600+ real-time data classifiers to what moves through prompts, parameters, and results, and enforces with graduated actions: allow, coach, notify, redact, redirect, or block. Redaction can mask a single field, redirect steers the session to the approved tenant, and the coaching users see is customizable. Most Aurascape customers use this graduated policy model, because most agent activity is normal work, so masking one field beats blocking an entire workflow. 

Assumption 6: A gateway in front of tool traffic is control 

Routing agent traffic through a gateway covers the paths someone configured. An agent can be pointed around a conventional gateway by editing one line of configuration, and MCP is one of several ways agents take action: there’s also connector use, direct API calls, code execution, protocols like A2A, and more.

This is an architectural distinction: How do you ensure that every agent tool call must go through a standalone AI or MCP gateway? If a call that skips the gateway raises no alert, the dashboards stay green while the activity they exist to govern happens somewhere else. The skip does not even require an attacker. A developer pointing an agent straight at a tool endpoint, a framework default, or an agent acting on an injected instruction all can result in bypassing the gateway. Enforcement that depends on the governed software cooperating is flawed. 

Questions to ask: If an agent’s tool call never routes through our gateway, what notices? What, other than configuration, forces agent traffic through the control point? Can we connect what the agent was instructed to do with the tool it ultimately invoked? 

The architectural answer uses two enforcement points that check each other. Within the governed architecture, Aurascape’s Zero-Bypass MCP Gateway marks every tool call it approves. The AI Proxy, watching the Intelligence Channel between the agent and its model, checks for that mark. An agent cannot use a tool without the call surfacing in the model conversation, so a call that skipped the Gateway shows up as unmarked and is blocked before the model acts. With the agent’s model traffic steered through the AI Proxy, unsanctioned tool execution does not complete. A standalone gateway cannot deliver that.

The other paths are covered where they surface: connector use, API activity, code, and agent actions are decoded and policy applied. 

What to check before letting an agent loose

The assumptions above, converted into a short checklist:

• Build an inventory of discovered agents: where each runs, its model, and its server and tool connections. Assign each a human sponsor. Discovery has to reach endpoints, because agents appear on developer laptops, in command-line tools, and as locally launched MCP servers, without going through procurement.
• Write the approved tool list explicitly, separating read from write and execute.
• Pin tool definitions at sanctioning time, and require review when a definition changes.
• Decide where classification runs on tool traffic, and require it to cover both directions: parameters going out, results coming back.
• Test against prompt injection, jailbreaks, and unsafe code before release, and retest when workflows change.
• Confirm action records name the user, the agent, the tool, the data or threat category, and the policy decision.

The additive AI interaction control layer

Aurascape does not replace your security service edge (SSE), cloud access security broker (CASB), secure web gateway (SWG), or data loss prevention (DLP) investments already in place. Those controls keep doing what they were built for, and agent governance is additive to them: a runtime layer that discovers the agents (the endpoint agent is what finds the local ones), decodes the exchange in both directions, applies policy on the tool call inline, protects data in motion, and keeps action-level evidence. The layer decodes the transports agents use, WebSockets, Protobuf, gRPC, QUIC, and SSE among them. Deployment is flexible: an endpoint agent, proxy chaining, or a browser extension brings traffic to the proxy.

The assumptions listed here were never careless. They held for years, and the teams that built programs on them built well. It’s just that, as overused as this phrase is, agents really do change everything. So, security has to move to exactly where the actions and the risk exist: the agent execution path.

If agents are already in your environment, start with a deeper dive into why intent is the new security perimeter, or book a demo and see the agentic activity in your environment.