Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is AI Agent Visibility and What Should Security Teams Actually Be Able to See?

AI agent visibility is a security team's ability to answer four questions from its own records: which agents exist, what each one was shown, what each one did, and who approved each consequential action. Most tooling answers one or two. A team that can answer only the first learns the fourth from an incident report instead of a record.

Application task modules feed a visible document workflow and a consolidated activity chart.

AI agent visibility is a security team's ability to answer four questions from its own records: which agents exist, what each one was shown, what each one did, and who approved each consequential action. Most tooling answers one or two. A team that can answer only the first learns the fourth from an incident report instead of a record. The question matters now because agents are no longer confined to a chat window. They hold their own cloud computers, read whole pages, operate applications through the interface, and change records and move money, often inside an employee's existing session. A team that can list its agents but cannot show what any of them read has an inventory, not visibility. The exposure principle is Least Exposure: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. Visibility is the evidence that the principle held. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Accenture reports that 77 percent of executives believe the true benefits of AI depend on a foundation of trust, defined as accuracy, predictability, consistency and traceability (Accenture, 2025).
  • McKinsey's State of AI 2026 finds 62 percent of organizations experimenting with AI agents and 23 percent scaling them anywhere, so most agents are still in pilots rather than a registry (CX Today, 2026).
  • Gartner states that uniform governance across AI agents will lead to enterprise AI agent failure, so the record has to say what each agent does (Gartner, 2026).
  • Agent documentation describes the model receiving the page in full: OpenAI's dots read webpage text and document content in connected apps, and AgentCore Browser's model perceives pages through screenshots and the DOM (OpenAI, 2026; AWS, 2026).
  • Microsoft's answer on Purview DLP and Copilot Studio computer use states that the documentation does not describe enforcement against the agent's browser session actions, so an estate control can be deployed and still miss the agent's data-movement step (Microsoft Q&A, 2026).
  • Paris, Moon and Guo argue that technical verification schemes for AI claims rest on unexamined assumptions a dishonest developer could exploit (Paris, Moon and Guo, 2026).

What does visibility mean for an AI agent?

For an application, visibility has meant logs: who signed in, which endpoints were called, what changed. An agent breaks that model because the actor is a model reading a rendered surface and deciding, step by step, what to do next. A log of calls shows what the agent did, not what it saw, and the next action depends on what it saw.

Four layers follow, each answered by a different kind of record.

Layer Question a security team should be able to answer Typical evidence
Existence Which agents run, on which applications, under whose identity? Inventory, identity registry
Exposure What did the model receive from each screen, document or tool result? The model's input, as received
Action What did the agent click, type, submit or change? Timestamped action log
Accountability Which named person approved each consequential action? Approval tied to the action

The layers are cumulative. Existence without exposure says an agent worked the claims system, not whether it read the policyholder's Social Security number on the way to the date of loss. Action without accountability shows a payment left, not who said yes. The NIST AI Risk Management Framework asks for Govern, Map, Measure and Manage (NIST, 2023); Measure is empty unless the four layers produce evidence a reviewer can inspect.

Accenture's Technology Vision 2025 defines trust in AI as accuracy, predictability, consistency and traceability, and reports that only 36 percent of organizations have scaled generative AI and 13 percent report significant enterprise-level impact (Accenture, 2025). Traceability is the visibility question restated as a business condition: tracing what the agent did back to what it saw and who allowed it.

Why is the inventory the first gap?

The existence layer should be the easy one, and it is not. McKinsey's State of AI 2026 reports 62 percent of organizations experimenting with AI agents against 23 percent scaling them anywhere (CX Today, 2026). The gap between those numbers is a population of pilots and individual experiments, the agents least likely to appear in any registry. The usual answer is a spreadsheet of approved agents kept by a governance committee, and it ages the day it is written. Consumer agents widen it: Claude in Chrome is a browser extension that takes screenshots of the active tab (Claude Help Center, 2026) and needs no change request to appear inside an enterprise application, carrying its user's permissions into every system that user can open.

The platform vendors have noticed. Amazon Bedrock AgentCore includes an Identity component and an Observability component with OpenTelemetry-compatible tracing (AWS, 2026). Such registries are real advances, with one limit: each sees the agents built on its own platform. An organization running two platforms plus whatever employees brought in has three partial inventories and no complete one.

Gartner's statement that uniform governance across AI agents will lead to enterprise AI agent failure adds a second requirement (Gartner, 2026). The record has to say which task each agent performs, because the right exposure and approval rules for a budget-transfer agent differ from those for a research agent. A companion page covers how organizations find agents they did not approve; for visibility, the inventory is the floor, and most tooling stops near it.

What was the agent shown, and why does most tooling not record it?

The exposure layer is where visibility most often fails, because the thing to record is not a request or a file transfer but the model's input: the screenshot, the page text, the document, the tool result. Vendor documentation agrees on what it contains. OpenAI's dots see webpage text and document content within connected apps (OpenAI, 2026). AgentCore Browser's model perceives pages through screenshots and the DOM (AWS, 2026). Claude in Chrome's documentation says all visible information, including personal data, becomes context (Claude Help Center, 2026). A separate page covers what an agent sees in a screenshot.

A team that does not record the model's input has no exposure layer; it infers what the agent saw from which application it opened. Where the input is recorded, the recording is a second copy of everything on the screen. Copilot Studio's computer-use audit offers session replay with screenshots and timestamped action logs, with verbosity configurable from all data down to minimal and retention from seven days to indefinite (Microsoft, 2026). AgentCore's session recording captures DOM changes, actions, console logs and network events to the customer's S3 bucket (AWS, 2026). That is good visibility and a new sensitive store in one artifact: if the screenshots hold real identifiers, the verbosity dial is a choice between seeing what the agent saw and retaining it.

Estate tools do not close the gap. Asked whether Purview DLP could detect or block a computer-use agent retrieving a file with PII and uploading it externally, Microsoft's moderator answered that the documentation does not describe enforcement against the agent's browser session actions or the data-movement step (Microsoft Q&A, 2026). OWASP lists Sensitive Information Disclosure as LLM02 in its 2025 Top 10, a risk that turns on what the model was given (OWASP, 2025). The exposure layer is the record of exactly that, and most stacks skip it.

What did the agent do, and who said yes?

The action layer is better served. OpenAI's Activity View lets the user follow, redirect or stop a dot's work, and Auto-review checks planned actions against instructions and Custom Rules before execution (OpenAI, 2026). Meta's Muse keeps an activity log and requires human approval before sensitive actions (Meta AI Research, 2026). AgentCore's Policy component applies deterministic control to tools and actions and its Observability component traces them (AWS, 2026). The action log exists; the question is what it is joined to, and three details in vendor documentation show how the join slips. Copilot Studio's human-supervision setting names a person to be emailed if the agent detects potentially harmful instructions, and the documentation notes that a reviewer other than the person running the agent likely does not see the activity and cannot properly verify the request (Microsoft Learn, 2026). OpenAI's Auto-review is a model reviewing a model's plan, recorded as a system check rather than a person's name (OpenAI, 2026). Claude in Chrome defaults to automatic approval with pauses on risky actions, with manual approval of every action as an option (Claude Help Center, 2026). In each case the action is logged; whether a named person approved it, in the same record, ranges from always to never.

OMB Memorandum M-24-10 asks federal agencies to apply minimum practices, including human oversight and monitoring, to rights- and safety-impacting AI (OMB, 2024). Oversight that cannot be reconstructed afterwards is an intention, not a practice. For any payment, submission or record change, can the team produce the approver's name, the time, and the screen that person saw? A page on who approves an AI agent's claim payment works one example.

Why is the vendor's own report not enough?

Most agent vendors offer visibility as a dashboard, a system card or a safety write-up. Those are not the organization's record. Paris, Moon and Guo argue that technical verification schemes for AI claims rest on unexamined assumptions and systematic fallacies a dishonest developer could exploit (Paris, Moon and Guo, 2026). A claim that an agent never sees a credential stays a claim until the team can check it against a record it holds.

Siddiqui and colleagues, in TMLR, show that poisoned data retrieved from one component of a larger system can coerce the model into spreading confidential data to untrusted components, and propose information-flow labels tracking which inputs influenced an output (Siddiqui et al., 2025). Once data is inside the model's context, visibility into where it went is a research problem. Greshake and colleagues demonstrated indirect prompt injection against real LLM-integrated applications, where instructions hidden in content the agent reads redirect it (Greshake et al., 2023); OWASP ranks the pattern first as LLM01 (OWASP, 2025). Recording the model's input is what lets a team see the injection that caused an action, not only the action.

The vendor that supplies the model also supplies the dashboard that reports on it and the review model that approves its plan. Separation of model and control is the principle that the environment deciding what an agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. Longer runs with less attention per step leave the record as the only place oversight lives.

How does a security team test its own visibility?

The test is a reconstruction. Pick one completed run and work the four layers in order, from records only.

Layer Question Common result
Existence Which agent, identity, applications, task? The platform registry, if the agent was built on one
Exposure What did the model receive on the third screen? Unanswerable, or only by replaying an archive of real values
Action What did the agent change, in order, with timestamps? The action log
Accountability Who approved the record change, and what were they shown? A system check, a shared mailbox or an automatic-approval setting

A run that passes all four in one place is visible. Three with a gap at exposure is the common and dangerous case, because exposure is where an incident starts and the other three are where it is noticed; an action log alone cannot tell an action the agent chose from one an injected page instructed.

Two design choices decide whether the exposure layer can be recorded safely: whether the model's input is reduced before it reaches the model, so the record holds tokens rather than values; and whether the record is written by an environment the organization owns and exported to its own monitoring, not retrieved from the vendor on request. A page on how to monitor what an AI agent actually accesses covers the logging mechanics; the visibility question is whether all four layers land in one record the team can query without asking anyone.

Where does RedactSure sit?

RedactSure's design produces the four layers as a by-product of how the agent works. The environment is a governed virtual machine in the customer's own cloud, so every agent inside it is known and tethered to the applications a named person chose, with no per-application integration and no change to user permissions. Every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, and the model receives the task's fields with identifiers as tokens such as SSN_001 and ACCT_001, so the record of what the model was shown holds tokens, not a second copy of real values. Under Supervised Delegation, 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 and approves every payment, submission and record change while it runs; real values resolve only at approved destinations at the moment of an approved action.

Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's own SIEM, with keys the customer holds and any model behind it. 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 read as of October 13, 2026. It rests on vendor documentation for the agents it names: OpenAI's safety write-up for dots; Anthropic's Claude in Chrome guidance; Meta AI Research on Muse; Microsoft Learn and the Microsoft Copilot Blog on Copilot Studio computer use; a Microsoft Q&A answer on Purview DLP; and AWS documentation for Amazon Bedrock AgentCore and its Browser tool. Framework sources are the NIST AI Risk Management Framework, OWASP's LLM01 and LLM02 entries and OMB Memorandum M-24-10; industry sources are Accenture's Technology Vision 2025, McKinsey's State of AI 2026 as reported by CX Today, and Gartner's May 2026 press release; research sources are Paris, Moon and Guo (ACM FAccT 2026, cited from the publication summary page), Siddiqui et al. (TMLR) and Greshake et al. (arXiv).

No product was tested, no agent was run, and no measurement of any vendor's logging is reported; statements about what each product records are limited to its documentation at the date of review. Vendor features change, and the page carries its date. The claims-system and budget-transfer examples describe kinds of work; no customer or prospect is described. Statements about RedactSure are limited to the design facts the company publishes about itself.

Whether an organization's visibility meets its obligations under any regulation, contract or policy is a determination for its counsel, its assessor and its security and compliance officers, not for the page.

What the record shows

Visibility into an AI agent is the ability to answer four questions from records the organization holds: which agents exist, what each was shown, what each did, and who approved each consequential action. Registries and action logs cover the first and third well, the fourth unevenly, and the second rarely, because the model's input is either not recorded or kept as an archive of real values. Inferring exposure from permissions is the gap an incident lands in. The test is one run, four layers, records only: if the third screen the model received cannot be produced with the name of the person who approved the step after it, the organization has an inventory, not visibility.

Frequently asked questions

What is the difference between AI agent visibility and an agent inventory?

An inventory answers the existence question: which agents run, where, under whose identity. Visibility adds three layers: what each agent's model was shown, what the agent did, and which named person approved each consequential action. Most organizations have a partial inventory per platform; far fewer can produce the screen the model received and the approval attached to the action after it.

Why is "what the agent was shown" so hard to see?

Because the thing to record is the model's input, which agent documentation describes as the page in full. Most stacks either do not capture it or capture it as session replay, an archive of real values. Recording the input as tokens, reduced before the model reads it, makes the exposure layer both visible and safe to keep.

Do action logs give a security team visibility?

One layer of four. Action logs show what the agent clicked, typed, submitted or changed, not what the model received before deciding, so an action caused by an injected instruction looks like a legitimate one. Nor do they, by themselves, name the person who approved a consequential action; that depends on whether approval is recorded as a named event joined to the action.

Is a vendor's safety dashboard or system card enough?

No. It is the vendor's account of its own product. Paris, Moon and Guo argue that verification schemes for AI claims rest on assumptions a dishonest developer could exploit, and the party supplying the model should not be the only party reporting on it. The organization needs its own record, written by an environment it owns and exported to monitoring it controls.

What does traceability have to do with visibility?

Accenture defines trust in AI as accuracy, predictability, consistency and traceability, with 77 percent of executives saying AI's benefits depend on that foundation. Traceability is visibility from the business side: tracing an agent's output back to what it saw and who allowed its actions. An agent that cannot be explained does not get scaled.

How quickly should a team be able to reconstruct a run?

From records alone, without a vendor request and without opening an archive of real identifiers. Pick one completed run and produce the agent's identity and task, the model's input on a chosen screen, the ordered actions with timestamps, and the named approval for each consequential step. If any layer requires an email or a vendor ticket, it is not visible.

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.