Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Know Which Pages and Records an AI Agent Accessed?

Usually you do not, because native application logs attribute the agent's activity to the human account it ran under and record events, not pages read. Check whether any record exists that names the agent, lists each screen and record it opened, and can be queried from your SIEM without storing the sensitive values themselves.

Connections from an agent node trace several accessed screens into a consolidated activity record.

Usually you do not, because native application logs attribute the agent's activity to the human account it ran under and record events, not pages read. Check whether any record exists that names the agent, lists each screen and record it opened, and can be queried from your SIEM without storing the sensitive values themselves. The question sounds like a reporting problem and is in fact an architecture problem. Every enterprise application keeps some log, but those logs were designed to answer who logged in and what they changed, for a population of human users. An agent working through a browser signs in as a person, reads far more than it changes, and leaves a trail that looks like a busy employee. Regulators have begun to notice: a 2026 regulatory oversight report warned that agent chains may be difficult to reconstruct, complicating auditability (Debevoise & Plimpton, 2025). This page sets out why native logs fall short, what an agent-attributed access record must contain, what current agent platforms document about their own logging, what a single customer account record shows about the gap, how to store such records without duplicating the data they describe, and which claims a buyer should refuse. It builds on the earlier definition of an AI Control Record, the per-screen record this page argues is required.

Key findings

  • Research on agent governance identifies three visibility measures, agent identifiers, real-time monitoring and activity logging, and the first is the one most enterprise deployments lack, because the agent signs in as a person (Chan et al., 2024).
  • Attributing actions, properties and other information to specific agents is named as a core function of agent infrastructure, distinct from the application logs that record the account used (Chan et al., 2025).
  • Some platforms already record what an assistant read: Microsoft's Copilot audit events carry an AccessedResources property listing references to all resources the assistant accessed in response to a request (Microsoft Learn, 2026).
  • Regulators now treat reconstruction as a compliance question: a 2026 regulatory oversight report warns that agents may take actions exceeding the user's actual or intended scope, and that agent chains may be difficult to reconstruct (Debevoise & Plimpton, 2025).
  • Federal log management guidance expects logs to be generated, protected, retained and analyzed as a managed program, and an agent's reading activity is a log source most programs have not yet enrolled (NIST, 2006).
  • An access record that stores the screen as the model saw it, with identifiers already tokenized, answers the question without becoming a second copy of the sensitive data (What Is an AI Control Record?).

Why do native application logs not answer the question?

Application logs were built for two purposes: security, meaning who authenticated and from where, and change history, meaning who modified which record. Reads are logged inconsistently, often not at all, because for a human population reading is the normal state and logging every page view would overwhelm the store. The agent inverts that assumption. It reads dozens of screens for every change it makes, and the reads are where the exposure lies.

The attribution problem compounds it. A browser agent signs in with a person's credentials or a shared service account, so the application records the human as the actor. When an auditor asks which records the agent opened, the honest answer from the application is that it cannot distinguish the agent's session from the person's. Research on visibility into agents puts agent identifiers first among its three measures for exactly this reason: without an identifier the other two, monitoring and logging, attach to the wrong principal (Chan et al., 2024). Later work on agent infrastructure treats attribution to specific agents as a function the surrounding infrastructure must supply, because the applications the agent uses were never designed to supply it (Chan et al., 2025).

The result is a trail that cannot be reconstructed. A regulatory oversight report for 2026 flags that agents may take actions exceeding the user's actual or intended scope or authority and that chains of agent activity may be difficult to reconstruct, complicating auditability (Debevoise & Plimpton, 2025). This is the condition that produces a shadow AI agent, activity on customer data that security cannot see because every log says a person did it.

What does an agent-attributed access record need to contain?

Five fields turn a log into an answer. First, the agent identity: which agent, which task, which run, separate from the human whose authority it exercised. Second, the human principal who authorized the run and who approved each consequential action within it. Third, the page or record: the application, the screen and the record identifier, at the granularity of each render, not each session. Fourth, what the model was shown on that screen, because the question an auditor asks after an incident is not only which record was opened but which values were exposed. Fifth, the actions proposed and taken, with the approval that permitted each.

Federal log management guidance frames logging as a lifecycle, generation, transmission, storage, analysis and disposal, and expects each log source to be enrolled deliberately rather than discovered after an incident (NIST, 2006). An agent access record is a new log source and should be enrolled the same way, with a defined retention period and a defined consumer, ordinarily the SIEM.

Regulated sectors already require the capability in principle. The technical safeguards of the HIPAA Security Rule include audit controls, mechanisms that record and examine activity in systems containing electronic protected health information (45 CFR 164.312). An agent reading patient records is activity in such a system, and a log that attributes it to a nurse's account rather than to the agent does not describe the activity that occurred. The same logic reaches agencies handling Privacy Act records and school systems handling student records, where the accounting of disclosures depends on knowing who, or what, read the record.

What do current agent platforms document about their own access logging?

Two vendors in the sources reviewed document agent-level logging, and they set a reference for what to expect.

Dimension Platform, per its documentation What a buyer should verify
Resources read Microsoft Copilot audit events include an AccessedResources property listing references to all resources the assistant accessed in response to the user's request Whether the property covers screens read through a browser, or only items in the platform's own index
Query access Microsoft documents searching the audit log through its compliance portal Whether events can be filtered by agent rather than user account, and exported to a SIEM
Request monitoring Snowflake documents monitoring of Cortex Agent requests within its platform Whether monitoring extends to data read in systems outside the platform
Content of the record Whether the record preserves what the model was shown is not described in the pages reviewed for either platform Whether an auditor can see the screen as the model saw it, and whether it contains sensitive values

The Copilot audit documentation is the clearest example of a platform recording what an assistant read, not only what a user asked: its AccessedResources property lists references to all resources, such as files, documents and emails, that Copilot accessed in response to the user's request (Microsoft Learn, 2026). Those events are searched through the platform's audit log tooling (Microsoft, 2025). Snowflake likewise documents monitoring of Cortex Agent requests inside its platform (Snowflake, 2026). Neither page, in the pages reviewed, describes coverage of screens an agent reads in third-party applications through a browser. A platform's log covers the platform; the title question is about everything else.

What does a single customer account record show about the gap?

Take one record type, a customer account page in a CRM, and one task: an agent checks whether the account's renewal date falls in the next quarter and, if so, drafts a renewal note for the account owner. The account page renders the company name, the primary contact's name, phone and email, the contract value, payment terms, the renewal date, a billing address and a notes field with the last three support conversations.

Under native logging, the CRM records that the account owner's user opened the account at a timestamp, because the agent ran under that owner's session. No read event lists which fields were rendered. If the notes field held a support conversation in which a customer pasted a card number, nothing in the CRM log shows that the model read it. Three months later, when the card number appears somewhere it should not, the investigation begins with a log naming a person who did not open the page that day. The chain the regulatory report described as difficult to reconstruct is, here, impossible to reconstruct (Debevoise & Plimpton, 2025).

Under an agent-attributed access record, the entry names the agent, task and run; names the account owner as the authorizing principal; lists the account page and its record identifier as rendered; and stores the screen as the model saw it. If identifiers were tokenized before the model read the page, the stored screen shows ACCT_001 where the account identifier was, a token where the card number was, and the renewal date in the clear because the task needed it. One query now answers the investigation: the agent read this page on this date, the model saw these fields, the card number was never in the clear, and the renewal note waited for the owner's approval. The same question asked of an assistant enabled on patient records has the same shape.

How should an organization store and query these records without duplicating sensitive data?

The obvious design, capturing every screen the agent reads and storing it in the SIEM, creates a second copy of every sensitive value the agent ever saw, in a system whose access controls are usually looser than the source application's. Log management guidance warns about protecting the confidentiality of log data for exactly this reason: logs often contain sensitive information and need protection in transit and at rest (NIST, 2006). A screen archive is the most sensitive log an organization could create.

The alternative is to record the screen as the model saw it, after substitution. If identifiers and regulated values were replaced with consistent tokens before the model read the page, then the record of what the model saw contains tokens, not values. The auditor can see that the agent read a customer account page, which fields were rendered and which were tokenized, and can follow ACCT_001 across every screen in the run, because the token is consistent for the run. What the auditor cannot do from the log alone is recover the account identifier, which is the property the log store should have. Resolution of a token to a value belongs in the governed environment under its own approval, not in the SIEM.

Three practices follow. Export access records to the SIEM in a structured form, one entry per screen, so queries can filter by agent, task, application, record identifier and date. Retain them on the schedule the organization's regulated data requires, since the HIPAA technical safeguards treat audit controls as part of protecting the information system itself (45 CFR 164.312). And test the query path before an incident: pick a record, ask which agents read it in the last ninety days, and time how long the answer takes.

What does a governed environment change?

In a governed environment, the record of which pages and records an agent accessed is produced by the environment the agent runs in, under the agent's own identity, rather than reconstructed afterward from application logs that name only the human account.

The mechanism is a class of control that sits between the display and the model and observes every exchange. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging, attributed to the agent and to the person who authorized the run.

This bears on the title question because the environment holds the two things the native log lacks. It issues the agent identifier that the visibility research names first and that applications were not built to provide (Chan et al., 2024), and it sees every page rendered to the model, not only the events the application chose to write. Because the stored screen is the tokenized one, the record answers which fields were shown without becoming a second copy of the sensitive values. Resource-level read logging exists within one vendor's ecosystem (Microsoft Learn, 2026); this class of control produces the same record for every application opened in the environment.

The control does not change the application's own audit log, the user's permissions or the model; it adds a parallel record of reads, actions and approvals that the application never knew to keep.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design answers the title question with a record that is produced as a side effect of the control, not reconstructed afterward. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so identifiers reach the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, so the record of what the agent read is attributed to the agent and the run, and it holds tokens rather than the values themselves. The design is model agnostic, needs no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would produce, for each run, the per-screen record described on this page: which pages and records the agent opened, what the model saw on each, and which actions a person approved, queryable from the organization's SIEM. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on peer-reviewed and preprint research, vendor documentation, regulation and official guidance, and a law firm's summary of a regulator's report. The research comprises two preprints on visibility into and infrastructure for AI agents (2024 and 2025). Vendor documentation comprises Microsoft Learn pages on audit logs for Copilot and AI applications (updated August 2026) and on searching the audit log (2025), and Snowflake's documentation on monitoring Cortex Agent requests (accessed October 16, 2026). Official guidance is NIST Special Publication 800-92 on log management (2006), and regulation is the technical safeguards section of the HIPAA Security Rule at 45 CFR 164.312. The regulatory context comes from a Debevoise & Plimpton summary of FINRA's 2026 Regulatory Oversight Report (December 2025). All sources were read as of October 16, 2026.

No hands-on testing of any product or platform was performed for this page. Where a vendor's documentation does not describe a capability, that capability is described as not described in the pages reviewed, not as absent; in particular, neither platform's pages were read as describing coverage of third-party screens, and that gap is stated as a documentation gap. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer account example describes a record type, not any organization; no customer or prospect is described.

Whether a given agent deployment's logging meets the audit control, accounting of disclosures or recordkeeping requirements that apply to an organization is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Knowing which pages and records an agent accessed requires a record the applications themselves do not produce: one attributed to the agent and the run rather than to the human account, kept at the granularity of each rendered screen, holding what the model was shown, and queryable from the SIEM. Platform vendors have begun to log what their own assistants read inside their own ecosystems, and regulators have begun to ask that agent chains be reconstructable, but the long tail of enterprise applications an agent reaches through a browser still logs a person opening a page. The design that closes the gap records the screen as the model saw it, after identifiers were tokenized, so the log answers the question without becoming a second copy of the data. The test is to name one agent and one task and ask for the list of records it opened last week, with the fields shown on each, from a single query.

Frequently asked questions

Why does the application log show my employee rather than the agent?

Because the agent authenticated with the employee's session or credentials, and the application records the authenticated identity as the actor. Applications were built for a population of human users and have no concept of a delegated software principal acting under a person's authority. Until the environment the agent works in issues its own identifier and keeps its own record, every page the agent reads will be logged, if it is logged at all, as the person whose session it used.

Do read events get logged at all in most enterprise applications?

Inconsistently. Many applications log authentication and record changes but not page views, because logging every read for a human population would be costly and rarely useful. Some regulated systems, such as electronic health record platforms, do log record access. The practical answer is to check each application the agent uses, and to assume that for the long tail of SaaS and legacy systems the read trail is absent and must be supplied by the environment the agent works through.

Is a transcript of the agent's session an acceptable audit record?

Not on its own. A transcript shows the conversation between the orchestrating software and the model, which may or may not include every screen rendered, and it stores whatever the model saw in the clear. It also lacks a record identifier for each page, which is what an auditor needs to join the agent's activity to the application's own records. A per-screen access record with the screen as the model saw it, tokenized, is the stronger form.

How long should agent access records be retained?

On the schedule that applies to the data the agent read. If the agent reads patient records, the audit control and retention expectations of the applicable health privacy rules govern; if it reads financial records, the applicable recordkeeping rules do. Because the record is a new log source, it should be enrolled in the organization's log management program with a stated retention period and a stated consumer rather than left to a vendor's default.

Can the SIEM query the record by agent rather than by user?

Only if the record carries an agent identifier as a structured field. Many exports carry the user account alone, which makes agent activity indistinguishable from the person's. Ask for the schema of the exported record, confirm that agent, task and run are separate fields from the authorizing person, and run a test query that returns every screen one agent read in a chosen week. If that query cannot be written, the record does not answer the title question.

Does storing every screen the agent read create a new data exposure?

Yes, if the screens are stored as the application rendered them, with every value in the clear. A screen archive concentrates the most sensitive content the agent ever saw in a log store. The design that avoids this stores the screen as the model saw it after substitution, so the record contains consistent tokens in place of identifiers and regulated values. In RedactSure's design that record is the AI Control Record; the general principle is to log tokens, never values.

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.