Your AI Vendor's Logs Are Not Your Evidence

In October, India's national CERT published a critical advisory, CIAD-2026-0049, about AI agents under evaluation that reached live systems of Indian organizations and read business records containing personal and confidential information. The detail every buyer of AI services should remember: none of the affected organizations detected the access. They found out because the AI model providers disclosed it.

That was the good outcome. The providers looked, found the activity, and said so. Now picture the same incident with a vendor that did not look, looked late, or decided the event did not meet its own threshold for disclosure. Your organization would have nothing. No record of what was read, when, or under which identity. No timeline to give your privacy officer, your regulator, or the people whose records were exposed.

If the only record of what an agent did on your behalf sits in someone else's system, you do not have evidence. You have a dependency.

What "evidence" means for an agent

The incident response practices published in October by NIST, the NSA and CISA are specific about what investigators need. Practice 5.3 asks for "tamper-resistant logs with reliable timestamps sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions." Practice 5.1 adds the rejected actions and tool calls, not only the successful ones. Practice 3.3 says agents must not be able to access or interfere with monitoring processes and logs.

Read those three together and the requirement is clear. The evidence has to be complete, it has to be trustworthy, and it has to be out of reach of the thing it records.

A vendor console fails on at least one of those counts for most buyers:

• Completeness. It shows what the vendor chose to record, in the format it chose, for the period its plan includes.
• Control. Its retention follows the vendor's policy and your subscription tier, not your incident timeline or your legal hold.
• Independence. During an incident involving the vendor's own platform, the vendor is a party to the investigation, not a neutral record keeper.

None of this makes vendor logs useless. They are a valuable second source. They are not the first one.

What to log on your side

You can hold most of the evidence yourself without the vendor's cooperation, because agents act through infrastructure you control. Four layers cover most of it.

1. A gateway for tool calls. Route agent tool calls and API requests through a proxy or gateway you operate, not directly from the agent runtime to the target system. The gateway records each call, its parameters, its result, and the policy decision: allowed, blocked, or sent for approval. It is also the natural place to enforce the approval gates described in our incident response post. One choke point gives you both control and evidence.

2. Identity provider logs. If every agent has its own identity, your identity provider already records every token it was issued, every resource it reached, and every failed attempt. If agents share a service account or borrow a person's token, these logs cannot tell agent activity apart from human activity. Fix the identity first, and the logs follow.

3. Egress logs. Record every outbound connection from the hosts where agents run: destination, port, protocol, bytes, result. CERT-In's advisory recommends that AI developers log destinations, ports, protocols, and results for agent activity, and that organizations restrict outbound traffic by default. A denied connection is a near-miss you can count.

4. Write-once storage. Ship all of the above to storage the agent and its operators cannot alter: object storage with a retention lock, or a log platform where deletion needs a separate privileged role. CERT-In recommends retaining logs for at least 180 days. Set your retention from your incident and legal needs, then make sure the vendor's contract cannot shorten it.

Then run the reconstruction test from our incident response post: if your model provider disappeared tomorrow, could you rebuild your agent's last 24 hours from your own records? Identity, tool calls, destinations, data touched, and every allow and block. If the answer depends on a support ticket, you have found your gap.

What to negotiate with the vendor

Your own logs cover what agents did through your infrastructure. They cannot see inside the vendor's platform: the prompts and reasoning, the vendor-hosted tools, the activity of other customers' agents on shared infrastructure. For that, you need the contract.

We are security practitioners, not lawyers. The points below are what we ask our clients' counsel to look for. Your counsel decides how to word them and what your jurisdiction requires.

• Log export. An API or scheduled export of agent activity logs, in a documented, machine-readable format, that you can pull into your own storage continuously. Not a dashboard, not a CSV on request.
• Retention you control. A retention period stated in the contract, and the ability to place a hold on specific records during an incident or dispute.
• Notification timelines. A defined maximum delay to notify you of a security incident affecting your data or your agents, with a named contact on each side. Include attempted and near-miss events, not only confirmed breaches.
• Transcripts during an incident. Access to full session transcripts, tool calls and timelines for the affected period. NIST practice 8.2 asks organizations to share "detailed timelines and transcripts" with affected parties where feasible. Make it a commitment, not a courtesy.
• Subprocessors. A current list of subprocessors that handle your data or run your agents, and notice before it changes.
• Right to audit. The right to verify compliance with these terms, directly or through an independent assessor, including after an incident.

For Quebec organizations, some of this is not optional. As our Law 25 post explains, section 18.3 requires a written contract when a provider handles personal information on your behalf. The contract must specify the provider's protection measures and bar it from keeping the information after the contract ends. The provider must notify your person in charge without delay of any violation or attempted violation of confidentiality, and let them verify compliance. Few standard AI vendor terms say that.

Why this matters before the incident

Every one of these points is cheap to secure during procurement and nearly impossible to obtain during an incident. At signature, you are a prospect the vendor wants to win. During an incident, you are one of many customers asking the same questions while the vendor protects itself.

The same is true of your own logging. A gateway, identity per agent, egress records, and locked storage take a few weeks to set up. Reconstructing an agent's actions without them can take far longer, and may not be possible at all.

How we help

• GenAI Security Readiness Assessment. A fixed-scope review of your agents' identities, gateways, egress controls, and logging, including whether your AI vendor terms give you the evidence you would need in an incident. Each gap comes with an owner and a remediation.
• Vendor review support. We review AI vendor security terms and documentation alongside your counsel and procurement team, and translate the technical requirements above into questions the vendor must answer before you sign.

Four questions to test yourself

1. For your most privileged agent, which of its actions are recorded only in the vendor's system?
2. Can an agent, or the team that operates it, delete or alter the logs that record its activity?
3. Does each AI vendor contract state how fast you will be told about an attempted breach, and give you access to transcripts during an incident?
4. If you needed the last 180 days of agent activity tomorrow, would you query your own storage or open a ticket?

If the honest answer to the last question is "open a ticket," your evidence belongs to someone else. That is a procurement problem today and an incident response problem later.