What Your AI Agent Platform Actually Logs: An Audit Evidence Matrix

A documentation review of six AI agent platforms, one verbatim quotation per cell, stamped to a date and scheduled for quarterly re-validation.

An AI agent with tool access is a privileged actor on your network, and the audit trail it leaves is not the audit trail most teams assume they are buying. We read the published audit and logging documentation for six AI agent platforms on 28 July 2026 and recorded, cell by cell with a verbatim quotation for each, what the documentation says is captured. Not one of the six documents tool call arguments inside a native audit log. Five document a native audit log. One, AWS, documents the individual tool call inside it, and in the same breath documents that the arguments in that record are redacted. Everywhere else, tool level detail lives in customer instrumented OpenTelemetry that somebody has to wire up before the incident, and on three of those four platforms it is off by default.

The rule that governs this entire page

"Not documented" is not "not present." A platform may log something it does not document. Every negative on this page and in the dataset behind it reports the state of the vendor's published documentation on 28 July 2026, not the behaviour of a running system. Nothing was tested, probed, or accessed to observe behaviour. This is a documentation review, and it is deliberately limited to that.

There is one exception, and it is a stronger claim rather than a weaker one. Where a vendor documents an absence, we say so. AWS states in its own documentation that request and response contents in AgentCore Gateway data events are redacted. That is a documented no, not a silence.

We also do not rank these platforms. There is no score, no total, no grade, no order of merit. Six organisations will weigh these six properties six different ways, and a league table would invite argument about exactly the thing that makes this useful. Cells report capability. You judge.

The direct answer

If an AI agent does something harmful on your systems, what will the platform's audit log actually show you?

On five of the six surfaces reviewed, the native audit log will show you that a principal interacted with an agent, when, from where, and often which resources the agent touched in the course of responding. On one of them, AWS CloudTrail with data events enabled, it will additionally show you which named tool was invoked, and it will tell you plainly that the arguments to that tool were redacted. On none of them, as documented on 28 July 2026, will the native audit log show you the arguments the agent passed to the tool.

To answer "what exactly did it do," you need the second surface: OpenTelemetry traces, agent tracing, or SDK instrumentation. That surface almost always has to be enabled in advance, it usually lives in a different system with a different retention policy and a different access-control model, and it is generally described by its vendor as an observability and debugging capability rather than as evidence.

What the matrix shows

• Native audit logs exist nearly everywhere. Microsoft, Anthropic, OpenAI, Google, and AWS each document a native audit surface an administrator can retrieve. This is not a story about missing logs.

• Tool call detail is the gap, not logging in general. The native audit logs are built around sessions, API calls, identity events, and configuration changes. Agent tool invocation is a newer unit of work and the audit schemas have not caught up with it.

• AWS is the only platform whose native audit log documents the individual tool call. The published AgentCore Gateway CloudTrail example records the Model Context Protocol method tools/call and the invoked tool name.

• AWS is also the only platform that documents redaction of the arguments. "arguments": "REDACTED" appears in that same published example. That is a designed privacy behaviour, and it is also an evidentiary limit you should plan around.

• Argument level detail is customer instrumented on every platform that documents it at all. Microsoft, Anthropic, and Google each document it in OpenTelemetry surfaces that are off by default. OpenAI's Agents SDK tracing is the outlier: it is on by default, and it exports to OpenAI's own backend.

• Only AWS documents cryptographic tamper evidence for the log itself. CloudTrail log file integrity validation hashes each delivered log file and signs hourly digest files. No other reviewed platform documents an equivalent mechanism.

• The Model Context Protocol defines no audit log at all. It defines a logging utility for servers to send diagnostic messages to clients, and it warns that token passthrough makes investigation harder. Everything evidentiary is left to the implementation.

The matrix

Accurate as of 28 July 2026. Every value below is backed by a verbatim quotation from the vendor's own documentation, stored with its source URL and retrieval date in the open dataset.

Reading the matrix, platform by platform

Microsoft Foundry Agent Service

Microsoft's native surface is Microsoft Purview Audit. The documentation is explicit that this is automatic rather than something you configure per application: "The system automatically generates audit logs when a user interacts with Copilot, Cowork, or an AI application," and applications "built using Microsoft Copilot Studio and Microsoft Foundry are included in Audit Standard" (Microsoft Learn, Audit logs for Copilot and AI applications, retrieved 28 July 2026).

What that record carries is genuinely useful for an investigation. It identifies the principal and the context: "These audit records contain details about which user interacted with Copilot, when the interaction took place, and where it occurred." It also carries a resource trail: "Audit records also include references to files, sites, or other resources Copilot, Cowork, and AI applications accessed to generate responses to user prompts," with a documented Action value on each accessed resource covering read, create, and modify. There is an AgentId property, documented as a "Unique identifier for an agent."

What it does not document is a per-tool-call record type. Tool calls appear on the other Microsoft surface, Foundry tracing, which captures "Tool usage, including tool calls and results" and defines an execute_tool span attribute tool.call.arguments that "Logs the arguments passed during tool invocation" (Microsoft Learn, Agent tracing in Microsoft Foundry, retrieved 28 July 2026). That surface is unambiguous about its default state: "Tracing is off by default," and "No trace data is collected or stored unless explicitly enabled by Foundry Account Owner or Foundry Owner" (Microsoft Learn, Microsoft Foundry Tracing and Data Handling, retrieved 28 July 2026).

Anthropic Claude Enterprise and Claude Code

Anthropic's native surface is the Compliance API Activity Feed, and its scope statement is the broadest of the five: "The Activity Feed records every authentication, chat, file, project, administrative, and platform action that occurs in your organization, in reverse chronological order." It also carries the longest documented retention in the matrix by a wide margin: "Activities are queryable within 1 minute of occurring and are retained for 6 years" (Anthropic, Query the Activity Feed, retrieved 28 July 2026).

The activity type reference documents hundreds of types. The MCP and tool related ones that are documented are policy and configuration events, for example mcp_tool_policy_updated, described as "The permission restriction for an MCP tool was set or cleared" (Anthropic, Activities reference, retrieved 28 July 2026). No documented activity type on that page represents an individual tool invocation.

One detail worth stealing regardless of which platform you run: reads of the audit data are themselves audited. "Calls to the Compliance API itself emit compliance_api_accessed activities" (Anthropic, Design your compliance integration, retrieved 28 July 2026). Auditing the auditors is a control most log pipelines skip.

Tool level detail lives in Claude Code's OpenTelemetry events, tool_result and tool_decision, which carry the tool name and, notably, whether the call was allowed or denied and whether that decision came from config, a hook, or the user. Argument capture is gated behind a second, separately defaulted flag: OTEL_LOG_TOOL_DETAILS will "Enable logging of tool parameters and input arguments in tool events and trace span attributes: Bash commands, MCP server and tool names, skill names, user-authored workflow names, and tool input," and the documentation records that flag as disabled by default (Anthropic, Monitoring usage, retrieved 28 July 2026). Tracing itself is "off by default."

OpenAI API platform and enterprise surfaces

OpenAI publishes its API platform audit log contract in its OpenAPI specification, which makes the coverage question unusually easy to answer precisely. The endpoint summary reads "List user actions and configuration changes within this organization," and the AuditLog schema is described as "A log of a user action or configuration change within this organization" (OpenAI, OpenAPI specification, retrieved 28 July 2026). The published AuditLogEventType enumeration is administrative throughout: API keys, logins and logouts, projects, rate limits, roles, SCIM, service accounts, users, tunnels, workload identity providers, and tenant settings. No model invocation or tool invocation event type appears in it. Actor attribution is well specified: the actor is "The actor who performed the audit logged action," resolving to "The user who performed the audit logged action" with id and email.

The enterprise side is where the documentation-only method hits its limit, and this is worth stating plainly rather than glossing. OpenAI's public Compliance API page positions the product exactly as you would want ("Use the Compliance API for security, legal, governance, and investigation workflows that require auditable records," and "Use the append-only compliance log stream for ongoing collection"), then defers the substance: "The authenticated Admin API reference is the source of truth for current access requirements, event coverage, routes, schemas, filters, retention, and request behavior" (OpenAI, Compliance API and audit events, retrieved 28 July 2026). That reference returned HTTP 403 to unauthenticated retrieval on 28 July 2026. So the OpenAI enterprise cells report the limits of public documentation, not the limits of the product. A prospective buyer cannot evaluate event coverage before signing, which is itself a procurement finding.

Tool level detail is documented in the Agents SDK, which "includes built-in tracing, collecting a comprehensive record of events during an agent run: LLM generations, tool calls, handoffs, guardrails, and even custom events that occur," where "Function tool calls are each wrapped in function_span()" and that span stores the inputs and outputs of the call (OpenAI, Agents SDK tracing, retrieved 28 July 2026). Uniquely among the reviewed platforms, "Tracing is enabled by default." That is a real difference in posture, with the corresponding caveat that it is developer observability exported to OpenAI's backend, not an administrator-facing audit log.

Google Cloud Gemini Enterprise Agent Platform

Google's native surface is Cloud Audit Logs, and it has the strongest documented default of the five: "You can't disable Admin Activity audit logs." The counterpart is equally explicit: "To receive Data Access audit logs, you must explicitly enable them" (Google Cloud, Agent Platform audit logging information, retrieved 28 July 2026). Identity attribution is well defined: "Audit logs record the identity that performed the logged operations on the Google Cloud resource," held in the AuthenticationInfo field (Google Cloud, Cloud Audit Logs overview, retrieved 28 July 2026).

The audited-operations table is expressed at API method level, and the agent relevant entries are session scoped rather than tool scoped: sessions.create, sessions.update, sessions.delete and sessionEvents.append under Data Access DATA_WRITE, with sessions.get, sessions.list and sessionEvents.list under DATA_READ. No per-tool-call operation appears in the table.

Google's tracing documentation contains the single most useful sentence in this entire review for anyone planning an evidence pipeline, because it separates the two switches most teams assume are one: "GOOGLE_CLOUD_AGENT_ENGINE_ENABLE_TELEMETRY enables the agent traces and logs, but doesn't include prompts and response data" (Google Cloud, Set up tracing, retrieved 28 July 2026). Turning telemetry on is not the same as capturing content. Content requires a second setting, OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT, at deploy time.

AWS Amazon Bedrock and Amazon Bedrock AgentCore

AWS is the platform whose native audit log gets closest to the tool call, and it is also the one that tells you most precisely where the evidence stops.

CloudTrail is the audit surface: "Amazon Bedrock is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Amazon Bedrock," and "Every event or log entry contains information about who generated the request" (AWS, Monitor Amazon Bedrock API calls using CloudTrail, retrieved 28 July 2026). Agent runtime operations are covered: "Amazon Bedrock logs all Agents for Amazon Bedrock Runtime API operations (such as InvokeAgent and InvokeInlineAgent) actions to CloudTrail as data events."

The word "data events" carries a configuration burden that catches teams out. Data events are not on by default: "You must explicitly enable data events as they are not captured by default" (AWS, Enable CloudTrail data event logging for AgentCore Gateway resources, retrieved 28 July 2026). Enable them, and the published AgentCore Gateway example shows a genuine tool-call record: the request parameters carry "method": "tools/call" and the invoked tool name, and additionalEventData carries the caller's JWT claims including subject, scope, and issuer.

Then the same page states the limit: "The contents of the requests and responses for data events are redacted, and the JSON Web Token (JWT) claims have HTML entities sanitized for security purposes," and the example duly shows "arguments": "REDACTED" (AWS, Understanding Amazon Bedrock AgentCore Gateway CloudTrail events, retrieved 28 July 2026). You can prove that a specific token holder invoked a specific named tool at a specific moment. You cannot read what it passed.

AWS is also alone in documenting cryptographic tamper evidence for the log itself: "To determine whether a log file was modified, deleted, or unchanged after CloudTrail delivered it, you can use CloudTrail log file integrity validation," which "is built using industry standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing" (AWS, Validating CloudTrail log file integrity, retrieved 28 July 2026). For anyone whose agent logs might one day be evidence in a dispute rather than just an input to a dashboard, that distinction is the whole ball game.

Richer span data, including the content CloudTrail redacts, comes from AgentCore Observability, where "Signals marked with an asterisk require explicit enablement" and "By instrumenting your agent code, you can also gather more detailed trace and span data as well as custom metrics" (AWS, AgentCore generated observability data, retrieved 28 July 2026).

The Model Context Protocol specification

The protocol is in the matrix because a growing share of real tool calls travel through it, so what MCP itself guarantees is a separate question from what any platform guarantees.

MCP revision 2025-11-25 defines tool invocation thoroughly: "The Model Context Protocol (MCP) allows servers to expose tools that can be invoked by language models," with a normative human-in-the-loop expectation that there "SHOULD always be a human in the loop with the ability to deny tool invocations" (MCP specification, Tools, retrieved 28 July 2026). What it does not define is any record of that invocation. Its logging section is a diagnostics channel, not an audit trail: "The Model Context Protocol (MCP) provides a standardized way for servers to send structured log messages to clients," with clients free to persist those messages or not (MCP specification, Logging, retrieved 28 July 2026).

The specification is also candid about the attribution problem, in language any incident responder will recognise. On token passthrough: "The MCP Server will be unable to identify or distinguish between MCP Clients when clients are calling with an upstream-issued access token which may be opaque to the MCP Server," and "Both factors make incident investigation, controls, and auditing more difficult" (MCP specification, Security Best Practices, retrieved 28 July 2026). The same section notes that over-broad scopes produce "audit noise" and obscure user intent per operation.

If your agents reach internal systems through MCP servers, the evidence you will have in an incident is whatever the host application, the server implementation, or the gateway in front of them chose to write down. That is a design decision someone on your side has to make, and it pairs directly with the connector-layer testing scope covered in our MCP server security assessment guide.

Where tool level detail actually lives

The pattern across five commercial platforms is consistent enough to state as a rule: the native audit log answers governance questions, and a second, customer instrumented surface answers forensic questions.

That split has four practical consequences that tend to surface at the worst possible moment.

1. Retroactive collection is impossible. Telemetry that was off during the incident produces nothing afterwards. Microsoft states it directly: no trace data is collected or stored unless explicitly enabled.

2. Two different retention clocks. The Claude Activity Feed documents six years. Foundry trace retention is whatever the connected Application Insights workspace is configured for. Those numbers will not match, and the shorter one governs what you can actually reconstruct.

3. Two different access-control models. Foundry trace data requires roles on the Application Insights or Log Analytics resource, and Microsoft warns that this data "might contain personal data and customer content." Your audit log readers and your telemetry readers are probably not the same group, and neither list is automatically correct.

4. Content capture is a separate switch from telemetry capture. Google's documentation is the clearest on this and the lesson generalises: enabling telemetry does not enable prompt and response capture, and Anthropic gates tool arguments behind a second flag that is disabled by default.

Methodology

Selection. A platform was included if it is materially used to run AI agents against enterprise systems and it publishes audit or logging documentation that is publicly retrievable without a customer account. Both conditions had to hold. That yields Microsoft, Anthropic, OpenAI, Google, and AWS, plus the Model Context Protocol specification because it is the layer an increasing share of tool calls traverse.

Excluded: agent frameworks and orchestrators that publish no audit or logging documentation of their own and simply inherit whatever the host platform provides; preview products with no public documentation; and any surface whose only documentation sits behind a customer login, because a documentation-only method cannot read it.

Source discipline. Official published vendor documentation only. No blog posts, no analyst summaries, no third-party write-ups, no support-forum answers. Where a vendor publishes its API contract as a specification file, we read the specification file.

Quote rule. Every yes or no cell is backed by a verbatim quoted sentence from that vendor's documentation, stored in the dataset with the document URL and the retrieval date. No quote, no cell.

Verification. Every stored quotation was re-fetched from its source URL and string matched against the live page. All 64 quotations passed on 28 July 2026. Whitespace and inline-markup normalisation was applied to the page text; the quotation text itself was never altered to force a match. This step caught and corrected two paraphrases before publication, which is precisely why it exists.

Negatives. Where documentation is silent, the cell reads "not documented as of 2026-07-28". It never reads "no". The one documented negative in the matrix, AWS argument redaction, is labelled as such because the vendor states it.

No testing. No platform was tested, probed, or accessed to observe behaviour. This is a documentation review by design. It tells you what a vendor is prepared to commit to in writing, which is the thing you can hold them to in a contract.

Version and date stamp. Every row carries a retrieval date of 28 July 2026. Vendor documentation changes constantly, so the stamp is the asset. Re-validation cadence is quarterly, with the next pass scheduled for 28 October 2026, and the revision log lives in the dataset.

What an incident responder can and cannot reconstruct

Take a concrete scenario. An agent with a database tool and a messaging tool exfiltrates a customer table at 02:14. What can you establish tomorrow morning?

From the native audit log alone, across the reviewed platforms, you can generally establish:

• That an identified principal interacted with an identified agent, at a specific time, from a specific address.

• Which agent, by identifier, and in Microsoft's case which resources it accessed and whether the access was a read, a create, or a modify.

• On AWS with data events enabled, which named tool was invoked and which token subject and scope invoked it.

• On Google, that an agent session was created, updated, or appended to, provided Data Access logs were enabled beforehand.

• Administrative context: who created the credential, who changed the policy, who granted the scope.

From the native audit log alone you generally cannot establish:

• What arguments were passed to the tool. On AWS this is documented as redacted; elsewhere it is not documented in the audit log at all.

• What the tool returned.

• Whether the invocation was approved by a human, denied by policy, or auto-allowed by configuration. Anthropic's tool_decision telemetry event carries exactly this, and it is telemetry, not audit.

• The model's reasoning or intermediate steps that led to the call.

• Whether a prompt injection in retrieved content triggered the sequence. Microsoft's audit schema is the only one reviewed that carries a relevant signal, an XPIADetected boolean on accessed resources.

That gap between the first list and the second is the gap this asset exists to name. It is not an argument that these platforms are badly built. It is an argument that the audit schemas were designed around users and API calls, and agent actions are a newer unit of work that the schemas have not yet absorbed. The practical response is not to wait for them to catch up but to decide, before deployment, which surface will hold your evidence and to turn it on.

If you want the adversarial view of what those agent actions look like when someone is deliberately driving them, our AI red teaming field guide for LLM and agentic apps covers the attack surface, and the OWASP Agentic AI Top 10 test coverage checklist maps the failure classes to concrete tests. For detection-side expectations, see our work on red team detection benchmarks.

Questions to ask a platform vendor before deployment

These are written to be pasted into a security questionnaire. Each one targets a distinction this review found to be load bearing.

1. Is tool-level detail in your native audit log, or in a telemetry product? Ask for the documentation URL for each. If the answer is telemetry, everything below applies to that surface, not the audit log.

2. Which of these is on by default in a new tenant, and which requires an explicit action? Name the action and the role that can take it.

3. Do you record the tool arguments, the tool name only, or neither? If arguments are redacted or truncated, ask for that to be stated in writing and ask what the threshold is.

4. Is the human principal who initiated the agent action carried through to the tool-call record? Delegation chains break attribution. Ask specifically whether the record shows the end user or only the service identity the agent used.

5. Is the approval decision recorded? Whether a call was auto-allowed by policy, approved by a human, or denied is often the single most important fact in an agent incident, and it is frequently in a different stream from the call itself.

6. What is the retention window for each surface, and can I extend it? Expect two different answers for the audit log and the telemetry, and plan for the shorter one.

7. Is there a documented tamper evidence mechanism for the log? Cryptographic integrity validation is rare. If it does not exist, say so in your risk register rather than assuming it.

8. Is reading the audit log itself audited? Ask whether administrator queries against compliance data generate their own records.

9. Can I evaluate your event coverage before I sign? If the complete event catalogue is only visible behind an authenticated reference, that is a procurement risk worth pricing.

10. What is your notice period for changing the audit schema? Audit pipelines are brittle. Silent event-type changes break detections.

For AI-specific vendor diligence beyond logging, our AI pentest data handling due diligence guide covers the adjacent questions about what a provider does with your data during testing.

Limitations

The OpenAI enterprise gap is the largest. Its public Compliance API page defers event coverage, schemas, filters, and retention to an authenticated reference that returned HTTP 403 to unauthenticated retrieval on 28 July 2026, as did the associated help-centre article. Those cells report the limits of public documentation and nothing more. If OpenAI publishes an unauthenticated event catalogue, we will update the matrix and note the change in the revision log.

Microsoft's classic surface was excluded from the cells. A ToolCalls platform metric with AgentId and ToolName dimensions is published in the Foundry Agent Service (classic) monitoring reference. It is a counter rather than a per-call record, and the classic agents surface is documented as deprecated with retirement scheduled for 31 March 2027, so we did not build a cell on it. It is recorded in the dataset's documentation-gaps section.

Documentation is not behaviour. A platform may capture more than it documents. It may also capture less. Only a controlled test on your own tenant tells you which, and running that test is a reasonable thing to do before you rely on any of these surfaces in an incident-response plan.

Vendor docs move. Three of the six platforms had reorganised or renamed the relevant documentation within the twelve months before this review. Google's Vertex AI audit documentation now resolves under Gemini Enterprise Agent Platform; Microsoft's Foundry observability documentation has both a current and a classic tree. Date-stamped citations are the only defence, which is why every cell carries one.

Get the dataset

The full matrix is published as an open dataset under CC BY 4.0, including the verbatim quotation and source URL for every cell, the documentation-gaps record, and a revision log.

• CSV: https://www.stingrai.io/data/agent-audit-log-matrix/matrix.csv

• JSON: https://www.stingrai.io/data/agent-audit-log-matrix/matrix.json

Attribution: Stingrai, Agent Audit Log Evidence Matrix, https://www.stingrai.io/blog/ai-agent-audit-log-evidence-gap

If a cell is wrong, or a vendor page has changed since 28 July 2026, tell us at hello@stingrai.io. Corrections are credited in the revision log and shipped in the next quarterly pass.

Frequently Asked Questions

If an AI agent does something harmful on my systems, what will the platform's audit log actually show me?

On five of the six surfaces reviewed on 28 July 2026, the native audit log shows that a principal interacted with an agent, when, from where, and often which resources the agent touched. On AWS with CloudTrail data events enabled, it additionally shows which named tool was invoked and which token subject invoked it. On none of them does the native audit log document capture of the arguments passed to the tool. Reconstructing what the agent actually did generally requires a separate telemetry surface that had to be enabled before the incident.

Do AI agent platforms log tool calls?

The native audit logs mostly do not, as documented. Microsoft, Anthropic, OpenAI, and Google document their native audit logs around sessions, API calls, identity events, and configuration changes, and none of them documents a per-tool-call audit record type. AWS is the exception: its published AgentCore Gateway CloudTrail example records the Model Context Protocol method tools/call along with the invoked tool name, once data events are enabled. Tool calls are widely captured in tracing and telemetry surfaces, which are a different product with different defaults.

Which AI agent platform records tool call arguments?

None of the six records tool call arguments inside a native audit log, as documented on 28 July 2026. AWS documents the opposite explicitly, stating that the contents of requests and responses in data events are redacted. Argument capture is documented in customer instrumented telemetry: Microsoft's tool.call.arguments span attribute, Anthropic's OTEL_LOG_TOOL_DETAILS flag, Google's OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT setting, and OpenAI's Agents SDK function_span.

What is the difference between an audit log and agent tracing?

An audit log is an administrator-facing record of who did what, designed for governance and investigation, usually with a defined retention window and an access-control model tied to compliance roles. Agent tracing is developer-facing telemetry designed for debugging and performance analysis, usually off by default, usually stored in an observability system with its own retention, and usually readable by a different group of people. Vendors describe them differently on purpose. Treating a tracing product as an audit trail is the most common mistake in this area.

Does the Model Context Protocol define an audit log?

No. Revision 2025-11-25 defines a logging utility that lets servers send structured diagnostic messages to clients at syslog severity levels, and it leaves persistence optional for the client. It defines no audit record, no retention requirement, and no field that carries the human principal into a tool call. Its security guidance warns that token passthrough leaves a server unable to distinguish clients and makes incident investigation harder.

Can I prove my AI agent audit log was not tampered with?

Only on AWS, based on published documentation as of 28 July 2026. CloudTrail log file integrity validation hashes every delivered log file with SHA-256 and signs hourly digest files using SHA-256 with RSA, and it must be enabled on the trail. No other reviewed platform documents an equivalent cryptographic mechanism for the audit log itself. If your agent logs may one day serve as evidence rather than as monitoring data, this distinction matters more than log volume.

What should I ask an AI agent platform vendor about audit logging before deployment?

Ask whether tool-level detail sits in the native audit log or in a telemetry product, which surface is on by default in a fresh tenant, whether tool arguments are captured or redacted, whether the human principal is carried through to the tool-call record, whether the approval or denial decision is recorded, what the retention window is for each surface, whether a tamper evidence mechanism exists, and whether reads of the audit log are themselves audited. Ask for a documentation URL with each answer.

Does this matrix rank AI agent platforms?

No, deliberately. There is no score, no total, and no order of merit. Different organisations weigh retention, tamper evidence, argument capture, and default-on behaviour very differently, and a league table would produce an argument about weighting instead of a usable reference. The matrix reports what each vendor documents per cell, with the quotation attached, so you can apply your own weighting.

Where can I get the underlying data?

The complete dataset is published under CC BY 4.0 at https://www.stingrai.io/data/agent-audit-log-matrix/matrix.json and https://www.stingrai.io/data/agent-audit-log-matrix/matrix.csv. It contains all 36 cells with the verbatim quotation, source title, source URL, and retrieval date for each, plus a documentation-gaps record and a revision log. Re-validation is quarterly, with the next pass scheduled for 28 October 2026.

References

Every source below is official published vendor documentation, retrieved 28 July 2026.

1. Microsoft. Audit logs for Copilot and AI applications. https://learn.microsoft.com/en-us/purview/audit-copilot. Purview Audit record generation for Copilot and AI applications, audit record properties including AgentId and AccessedResources, and retention for pay-as-you-go AI application interaction logs.

2. Microsoft. Agent tracing in Microsoft Foundry. https://learn.microsoft.com/en-us/azure/foundry/observability/concepts/trace-agent-concept. OpenTelemetry semantic conventions for agent tracing, including the execute_tool span attributes for tool call arguments and results.

3. Microsoft. Microsoft Foundry Tracing and Data Handling. https://learn.microsoft.com/en-us/azure/foundry/observability/concepts/trace-data. Default state of Foundry tracing, enablement path, storage location, retention governance, and access-control requirements.

4. Anthropic. Compliance API. https://platform.claude.com/docs/en/manage-claude/compliance-api. Scope of the Compliance API across activity, chats, files, projects, and users, and key types required for access.

5. Anthropic. Query the Activity Feed. https://platform.claude.com/docs/en/manage-claude/compliance-activity-feed. Coverage statement for the Activity Feed, availability latency, and the documented six-year retention.

6. Anthropic. Activities (Compliance API reference). https://platform.claude.com/docs/en/api/compliance/activities. Full documented activity-type catalogue including MCP tool policy and configuration event types.

7. Anthropic. Design your compliance integration. https://platform.claude.com/docs/en/manage-claude/compliance-integration-patterns. Actor fields for SIEM correlation and the self-auditing behaviour of Compliance API reads.

8. Anthropic. Monitoring usage (Claude Code). https://code.claude.com/docs/en/monitoring-usage. OpenTelemetry configuration, tool_result and tool_decision event definitions, and the default-disabled tool detail flag.

9. OpenAI. OpenAI OpenAPI specification. https://github.com/openai/openai-openapi/blob/master/openapi.yaml. Published audit logs endpoint, AuditLog and AuditLogActor schemas, and the complete AuditLogEventType enumeration.

10. OpenAI. Compliance API and audit events. https://developers.openai.com/codex/enterprise/compliance-api. Positioning of the Compliance API, the append-only stream, and the deferral of event coverage to an authenticated reference.

11. OpenAI. Tracing (OpenAI Agents SDK). https://openai.github.io/openai-agents-python/tracing/. Default-on tracing behaviour, span types including function_span, and sensitive-data capture controls.

12. Google Cloud. Agent Platform audit logging information. https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/general/audit-logging. Audit log types available for the Agent Platform, enablement rules, and the audited-operations table.

13. Google Cloud. Cloud Audit Logs overview. https://docs.cloud.google.com/logging/docs/audit. Identity recording in the AuthenticationInfo field and retention governance for audit log entries.

14. Google Cloud. Set up tracing. https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/tracing. Cloud Trace enablement for deployed agents and the separation of telemetry enablement from message-content capture.

15. AWS. Monitor Amazon Bedrock API calls using CloudTrail. https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html. CloudTrail integration, identity recording, and classification of Bedrock Agents runtime operations as data events.

16. AWS. Monitor model invocation using CloudWatch Logs and Amazon S3. https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html. Full request and response capture through model invocation logging, and its default-disabled state.

17. AWS. Enable CloudTrail data event logging for Amazon Bedrock AgentCore Gateway resources. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/enabling-cloudtrail-data-event-logging.html. Requirement to explicitly enable data events and the advanced event selectors needed.

18. AWS. Understanding Amazon Bedrock AgentCore Gateway CloudTrail events. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/understanding-gateway-cloudtrail-log-entries.html. Published InvokeGateway data event examples showing the tools/call method, tool name, JWT claims, and argument redaction.

19. AWS. Validating CloudTrail log file integrity. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html. Hashing and digital signing mechanism for delivered log files and digest files.

20. AWS. Amazon Bedrock AgentCore generated observability data. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-service-provided.html. Service-provided signals by resource type and which signals require explicit enablement.

21. Model Context Protocol. Tools, specification revision 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/server/tools. Tool exposure and invocation model, and the human-in-the-loop expectation for denying invocations.

22. Model Context Protocol. Logging, specification revision 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/logging. The logging utility, capability declaration, severity levels, and optional client persistence.

23. Model Context Protocol. Security Best Practices, specification revision 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices. Confused deputy and token passthrough analysis, including the accountability and audit-trail consequences.

24. Model Context Protocol. Versioning. https://modelcontextprotocol.io/specification/versioning. Confirms 2025-11-25 as the current protocol version at the retrieval date.

Where Stingrai fits

Agent platforms are assessed by people, not scanners. Working out what your agent stack will actually be able to prove after an incident means reading the deployment, not the brochure: which surfaces are enabled in your tenant, whether the human principal survives the delegation chain into the tool call, whether the MCP servers in the path add or destroy attribution, and whether the evidence you would need is being written down at all today.

Stingrai is a CREST-accredited penetration testing service provider, founded in 2021, with offices in Toronto and London. Our red team engagements exercise agent-driven attack paths end to end and tell you exactly which of them your logging would and would not have caught, which is the same evidence your SOC 2, ISO 27001, and DORA programmes need to show that agent activity is monitored. That agent-platform work is human led. Snipe, our autonomous AI agent, is scoped to web application penetration testing, where it hunts IDOR, business logic, and broken authorization flaws in the applications your agents sit behind.

If you are deploying agents with tool access this quarter, talk to us about scoping an assessment before the evidence question becomes an incident question.