Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Tool Access and How Should Companies Control Which Systems an Agent Can Use?

AI agent tool access is the set of systems an agent can act through, from APIs and MCP servers to connectors and browser actions, and the scope it holds on each. Grant them per task, with a named person on consequential actions, or an agent with legitimate access becomes the channel through which injected content reaches real systems.

An AI task module connects tools through a permission gate with separate destination switches.

AI agent tool access is the set of systems an agent can act through, from APIs and MCP servers to connectors and browser actions, and the scope it holds on each. Grant them per task, with a named person on consequential actions, or an agent with legitimate access becomes the channel through which injected content reaches real systems. Tools are the agent's hands. A model on its own produces text; the moment it can call a function, open a page or write a record, its output becomes an event in a system the organization runs. The question has two halves that get confused: which systems the agent may touch, and what each system hands back when it does. The second half carries most of the risk, because every tool result is content the model reads and can be persuaded by. Supervised Delegation keeps a named person on the consequential end of each tool call: that person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • OWASP lists Excessive Agency as LLM06 in its Top 10 for LLM Applications 2025, the failure in which an agent holds more functionality, more permissions or more autonomy than its task requires (OWASP, 2025).
  • Indirect prompt injection works through what tools return: malicious instructions embedded in a web page, a calendar entry, an email or a database field cause the agent to follow the attacker rather than the user (Bhagwatkar et al., 2026), a pattern first demonstrated against deployed LLM-integrated applications in 2023 (Greshake et al., 2023).
  • Two model-agnostic controls at the agent-tool boundary, a Tool-Input Firewall that strips unnecessary data from what goes to a tool and a Tool-Output Firewall that cleans what comes back, reach near-zero attack success on four agent security benchmarks with high utility (Bhagwatkar et al., 2026).
  • Tool surfaces are growing faster than governance: OpenAI's Dots connect to more than 4,000 apps through plugins, each dot with its own cloud computer and browser (The Next Web, 2026), and Meta's Muse for Small Business connects to Shopify, Stripe, QuickBooks, Slack, Dropbox and a dozen more services plus custom connectors (TechCrunch, 2026).
  • Executives expect the reach to widen: 29 percent expect agents to access functions in third-party systems within three years, and 38 percent expect agents to access data from across the organization in the same window (Accenture, 2025).
  • Gartner warned in May 2026 that applying uniform governance across AI agents will lead to enterprise AI agent failure, which for tool access means scope has to be set per agent and per task rather than by one standing policy (Gartner, 2026).

What counts as a tool for an AI agent?

A tool is anything the model can invoke that has an effect outside its own text. A function the developer registered with the model is a tool. So is an MCP server that exposes a ticketing queue or a database as callable operations, a connector a vendor supplies for QuickBooks or Slack, and a browser the agent drives by clicking, typing and submitting forms on the organization's own applications. In each case the model emits a structured request, something outside the model executes it, and the result comes back into the model's context as new input.

Four families cover most deployments, and they differ in who built the interface and how much comes back.

Tool family What it is Who built the interface Typical return
Native function A function the deploying team wrote and registered with the model The organization Whatever the team chose to return
MCP server A standardized server exposing a system's operations to any compatible agent The system's vendor, a third party or the organization The server's defined response, often a full object
Vendor connector A packaged integration inside an agent product (Dots plugins, Muse connectors) The agent vendor What the application's API returns
Browser action The agent operating an application through its screen Nobody; the application's own interface The rendered page, in full

A native function can be written to return three fields. A connector returns what the application's API returns, which for a customer or vendor record is usually the whole record. A browser action returns the whole page. The organization controls the shape of the first and rarely the other three, which is why tool access cannot be judged by a list of system names alone. The same system reached three ways exposes three different amounts of data, so the choice of path, the screen or an API and MCP, is part of the access decision.

Why is tool access different from a user's access?

A person with access to a billing system brings judgment to every screen: the person knows which fields the task needs, ignores the rest, and would notice if a vendor note said to change the remittance address. An agent brings a model that reads everything returned to it and treats instructions in that content as candidates for action. Tool access therefore has to be judged along four dimensions that user access reviews usually collapse into one.

The first is reach: which systems the agent can call at all. The second is scope on each system: read or write, which objects, which operations. The third is exposure: how much of each object comes back into the model's context when the tool runs. The fourth is autonomy: which calls proceed on the agent's own decision and which wait for a person. OWASP's Excessive Agency entry describes failures across the first, second and fourth as excessive functionality, excessive permissions and excessive autonomy (OWASP, 2025). The third, exposure, is where least privilege stops short of what the AI sees: an agent can pass a permission review and still receive a full patient or policyholder record from a tool that was correctly granted.

Identity is the other difference. An agent usually runs under a person's session or a service account, and its tool calls inherit that identity's permissions, so the person who granted the access answers for everything the agent does with it, including actions the person never saw. A user-access model has no place to record that a person approved one call and not the next, the gap that agent identity and agent access control take up on their own pages. The tool-access question is narrower: for this run, which hands does the agent get, and how long does it keep them.

How should a company decide which systems an agent may use?

Per task, not per agent, and never per platform. An agent product that ships with 4,000 app connections is offering reach, and reach is not a policy. The organization sets the policy by starting from the work and listing the systems it requires, the operations on each, and the fields the model needs to reason. Everything outside that list is withheld for that run, whatever the platform could connect to. Four decisions produce a usable scope.

Decide the system list from the workflow, not the catalog. A payables task touches the ERP, the vendor portal and the mailbox. It does not touch the HR system, even though the same identity could open it.

Decide the operation set on each system. Reading an invoice, preparing a payment and releasing a payment are three operations with three consequence levels. Grant read where the task needs it, grant prepare where the task is to draft, and keep release with a named person. This is the autonomy dimension OWASP names, settled before the run rather than during it (OWASP, 2025).

Decide what the model receives from each call. This is the decision user-access reviews skip. A connector that returns the full vendor record delivers bank details the drafting task never needed. The control is to minimize at the boundary: the Tool-Input Firewall in the ServiceNow and Mila research strips unnecessary data from what goes to a tool, and the same logic on the return path limits what the model is handed (Bhagwatkar et al., 2026). Where the agent works through a screen, the equivalent is to tokenize the identifiers on the rendered page before the model reads it, so the model receives ACCT_001 in place of the account number and still completes the match. Least Exposure is the principle: for each piece of work, the AI receives exactly the data the task requires and nothing more.

Decide how long the grant lasts. A scope confirmed for one run should end with that run; standing access is how a scope set carefully in March is still in force, unexamined, in September. Dots' Custom Rules let users set what a dot may do on its own, and OpenAI's documentation says Custom Rules cannot override mandatory confirmations for sensitive operations (OpenAI, 2026), which is a vendor deciding the consequence floor. An enterprise sets its own, and whether an agent should ever hold an "always allow" setting has its own page. Gartner predicts that uniform governance, one policy for every agent regardless of what it touches, will fail (Gartner, 2026). A per-task scope is the opposite of uniform, and it is the only form a reviewer can test against a run record.

Why are tool outputs an injection path?

Every tool call has a return path, and the return path is content. A page the browser fetched, a calendar entry the connector read, a ticket body the MCP server returned, a row from a database field: each arrives in the model's context as text the model reads with the same attention it gives the user's instruction. If that text contains an instruction, the model may follow it. Greshake and colleagues named this indirect prompt injection in 2023, showing deployed LLM-integrated applications redirected by content they retrieved rather than by anything the user typed (Greshake et al., 2023). OWASP places prompt injection at LLM01, first in its 2025 list (OWASP, 2025).

Tool access turns that from a nuisance into an incident. A model with no tools that is injected produces a wrong paragraph. A model with a payments tool that is injected can prepare a wrong payment. The attacker does not need to reach the agent directly; the attacker places content where a tool will return it, and the agent's legitimate access does the rest. Microsoft's AI Red Team catalogs this among the failure modes specific to agentic systems (Microsoft AI Red Team, 2025). Once the content is inside the context, tracing where it flows is itself a research problem: Microsoft Research's information-flow work treats the LLM as one component in a larger system where poisoned data retrieved from one component can coerce the model into spreading confidential data to another (Siddiqui et al., 2025).

The vendors' own defenses confirm the shape of the problem. OpenAI says Dots combine model safeguards with tool restrictions, checks before actions and monitoring to keep injected content from turning into an unwanted action (OpenAI, 2026). Meta's Muse write-up names injection via observed web data as a known risk and routes every network egress through a separate Sentinel that must approve it (Meta AI Research, 2026). Both are controls on the action side of the tool. Training the model to prefer privileged instructions helps on the reading side (Wallace et al., 2024), but refusal is a model-internal control with known holes, which MIT Technology Review describes as a stack of Swiss cheese layers each hoped to cover the others (MIT Technology Review, 2026).

The firewall research points at a different layer. The Tool-Output Firewall, the Sanitizer, cleans what comes back from a tool before the model reads it, and the authors report near-zero attack success on AgentDojo, Agent Security Bench, InjecAgent and tau-Bench with high utility (Bhagwatkar et al., 2026). The same paper warns that the public benchmarks are weak and easily saturated, so a vendor's "100 percent" claim on a benchmark deserves scrutiny. The durable point is structural: minimizing what reaches the model from a tool beats trying to detect every hostile instruction in it. An injection that succeeds against a model holding tokens rather than identifiers collects tokens, and if the consequential action still waits for a named person, the injection has produced a request, not an event.

What should a tool-access policy record?

A policy that cannot be checked afterward is an intention. For each run, the record should show the scope that was set and whether the run stayed inside it. Five items make that possible.

The approved system list and operation set for the task, with the name of the person who confirmed it. The content the model received from each tool call, as the model received it, so a reviewer can see whether identifiers were present. Each action the agent requested, each approval with a name and time, and each action that was declined or stopped. Any tool result that contained instructions the agent did not act on, since that is the evidence of an attempted injection. And the moment real values were used at a destination, because that is where the scope decision becomes consequential.

Those items are what an AI Control Record holds: every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. The NIST AI Risk Management Framework asks organizations to Map the systems an AI touches, Measure its behavior with evidence and Manage what the measurements show (NIST, 2023); for tool access, the per-task scope is the Map, the run record is the Measure, and the scope revision is the Manage. Accenture's definition of operational trust, accuracy, predictability, consistency and traceability, makes the same demand from the business side: traceability is a trust condition, not a reporting feature (Accenture, 2025).

Credentials belong in the record only as events, never as values. The tool-access question and the credential-protection question meet at the login: an agent that holds the secret that unlocks a system has access to everything the secret unlocks, which is reach without scope. Dots' secure sign-in sends credentials to the browser environment without exposing them to the model's context (OpenAI, 2026), and Muse uses surrogate tokens the agent cannot read (Meta AI Research, 2026). Both separate possession of the credential from use of the tool, which is the right shape; the enterprise version of that shape also needs the organization, not the vendor, to hold the record and the keys.

Where does RedactSure sit?

RedactSure gives the agent its hands inside a governed environment the customer owns. The agent works the organization's existing applications through their screens, with no per-application integration and no change to user permissions, so the system list is whatever a named person connected the tethered agent to and nothing beyond it. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run. Render-layer tokenization replaces identifiers chosen by policy with consistent tokens before any model reads the page, so what a tool returns to the model is the task's fields with SSN_001 and ACCT_001 in place of the values, and real values resolve only at approved destinations at the moment of an approved action. Every payment, submission and record change waits for that named person under Supervised Delegation, who can watch, pause and take over the same tokenized stream.

Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's SIEM. The environment runs on hardware-encrypted enclaves with keys the customer holds, and it is model agnostic, so the tool scope does not move when the model changes. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page is a definitional synthesis. It rests on standards and research read as of October 13, 2026: the OWASP Top 10 for LLM Applications 2025 entries LLM01 and LLM06 (industry standard); the NIST AI Risk Management Framework (official guidance); the ServiceNow, Mila and partner institutions' study of tool-boundary firewalls against indirect prompt injection (arXiv 2510.05244, preprint, v2 March 2026); Greshake et al. on indirect prompt injection (arXiv 2302.12173, preprint and AISec 2023); Wallace et al. on the instruction hierarchy (OpenAI preprint); Siddiqui et al. on information-flow analysis for LLMs (TMLR, peer-reviewed); and the Microsoft AI Red Team taxonomy of agentic failure modes (whitepaper). Vendor statements about OpenAI Dots and Meta Muse come from those vendors' own published safety write-ups and from press coverage of their September 2026 launches, cited as vendor documentation and press. The Accenture and Gartner figures are reported as those publishers state them.

No product was tested. No agent was run against any tool, MCP server or connector, and the benchmark results reported are the paper's own, not a replication; the paper itself cautions that the public benchmarks are weak and easily saturated. Vendor features and connector catalogs change, and the page carries its date and is revised when the sources change. No customer or prospect is described. Statements about RedactSure are limited to the design facts the company publishes about itself.

Whether a given tool scope meets an organization's obligations under HIPAA, PCI DSS, GLBA, FERPA or any other regime, or satisfies its own access policy, is a determination for its counsel, its assessor and its security and compliance officers.

What the record shows

Tool access is where an agent stops producing text and starts producing events, and it has to be decided per task along four dimensions: which systems, which operations, how much of each object reaches the model, and which calls wait for a person. The alternative, granting a platform's full catalog under a standing identity, leaves the organization with an agent whose reach was set by a vendor, whose exposure was set by each API's default response, and whose actions nobody approved. Because every tool result is content the model reads, an injection placed where a tool will return it rides the agent's legitimate access into real systems. The test a reader can apply is to take one completed run and ask for the scope that was confirmed, what each tool returned to the model, and who approved the step that changed a record. A deployment that cannot produce all three has granted hands without governing them.

Frequently asked questions

What is the difference between an API, an MCP server and a connector for an AI agent?

All three let an agent call a system without a screen. An API is the system's own interface; the deploying team decides how to call it and what to return. An MCP server wraps a system's operations in a standard any compatible agent can use, and returns what the server defines. A connector is a packaged integration inside an agent product and returns what the underlying API returns. The organization controls the shape of the first, and rarely the other two.

Does giving an agent read-only access make tool access safe?

No. Read-only access limits what the agent can change but not what it receives or what it can be persuaded by. A read-only connector can return a full customer record the task never needed, and a read-only page fetch can carry injected instructions into the model's context. Read-only settles the operation dimension and leaves exposure and injection open, which is why scope has to cover what comes back, not only what goes out.

Why are tool outputs more dangerous than the user's prompt?

Because the attacker does not need the user. Content placed where a tool will return it, a web page, a ticket, an email, a database field, arrives in the model's context with the same standing as everything else it reads, and the agent's legitimate tool access carries any instruction it follows into a real system. The user's prompt is one input the organization can see; tool outputs arrive from systems and the open web on every call.

Should tool access be set per agent or per task?

Per task. The same agent drafting a payment and releasing a payment needs two different scopes, and the same connector that is right for one workflow hands a second workflow data it never needed. Gartner predicts that uniform governance across agents will fail, and a per-task scope is the opposite of uniform: it names the systems, operations and fields one run may use, confirmed by a named person, and it ends when the run ends.

Can a firewall at the tool boundary stop prompt injection?

The published research reports near-zero attack success for a Tool-Output Firewall that sanitizes what comes back from a tool, with high utility, across four benchmarks. The same authors warn that those benchmarks are weak and easily saturated. The durable principle is minimization: the less of a tool's return that reaches the model, and the fewer real values it holds, the less an injection can collect, and a named person on each consequential action turns a successful injection into a request rather than an event.

How does tool access work when the agent operates applications through the screen?

The screen is the tool, and the page is the tool output. The agent reaches any application the organization already runs, with no API or MCP server required, and the control sits at the render layer: identifiers on the page are replaced with consistent tokens before the model reads it, the person who connected the agent chose which applications it can open, and consequential actions on each screen wait for that person's approval. The return path is governed by what the model is allowed to see.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.