Most companies now count AI agents as insiders, and CISOs worry about their own liability

When the agent is already inside

Imagine leaving your office keys with a bright assistant who never sleeps, never forgets and has access to everything you do. That assistant can book meetings, change orders, approve expenses and send emails in your name. Now imagine trying to explain, six months later, what that assistant did on a Tuesday in March.

That is roughly where most organisations now find themselves with AI agents. A Trellix survey of 600 CISOs found that 78% of companies now count AI agents and machine identities as insiders, alongside employees and contractors ^[1]. Not external threats to be kept out, but entities that already have the keys.

The shift makes sense. An AI agent doesn't arrive at the office with a stolen password. It acts using credentials it has been given, often the same credentials a person would use. From a system's point of view, the agent looks like any other authorised user.

The incidents are already happening

The same survey found that 95% of companies experienced an insider incident involving AI agents or autonomous systems in the past year ^[1]. The report doesn't break down what those incidents were, but the categories are familiar: unauthorised access, data exfiltration, misuse of credentials and actions that shouldn't have been taken.

What makes agents different from people is speed and scale. A person with access to a customer database might look up one record. An agent with the same access could query thousands in seconds, without anyone noticing until the bill arrives or a customer complains.

CISOs are noticing. The survey reports growing concern about personal liability when agents act using employee credentials and access sensitive systems ^[1]. That concern isn't hypothetical. When something goes wrong, the question lands on someone's desk: who knew what the agent could do, who approved it and who was watching?

What the rules ask for

Under the EU AI Act, high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[2]. The rule applies to systems in Annex III from 2 December 2027 and to systems in Annex I from 2 August 2028 ^[2]. The logs are there so you can trace what the system did, for follow-up after it has been placed on the market and for the user's own monitoring.

The Act says what to log. It doesn't say how to protect the logs, or how to show that a log hasn't been edited after the fact. That is a separate question, and one that matters more when the entity doing the logging could also change it.

For financial firms, DORA's technical standard on ICT risk management is more explicit: logs must be protected against tampering, deletion and unauthorised access ^[3]. That applies now, since 17 January 2025 ^[3].

The evidence gap

The question every CISO should be asking is this: if an agent does something questionable, could we show exactly what it did, when it did it and on whose instruction?

Most logging systems record the instruction, the tool call and the result. That is the easy part. The harder part is showing that the record is the one written at the time, not one edited later to make the incident look less serious or the response look faster.

Access controls help. Monitoring helps. But when the people who keep the logs are the same people who could change them, there is a trust problem. Auditors, supervisors and, in some cases, courts want to know not just that a log exists, but that it can be relied on.

What a digital witness does here

This is where a digital witness fits. The thing to seal is each instruction the agent receives, each tool call it makes and each result it gets back. Sealing takes a fingerprint of the record, not the record itself, so the log stays in your systems.

When someone questions what the agent did, you calculate the fingerprint again. If it matches the sealed one, the record hasn't changed. Change a single character and it won't match. The check can be done by anyone you share the record with: an auditor, a supervisor or your own incident response team.

What it doesn't do is authorise the action, make it correct or decide whether the agent should have had that access in the first place. Those are governance questions. A digital witness answers the narrower question: is this the record you wrote on that day?

WitniumChain handles the sealing through a REST API, an SDK or an MCP server that agents can call directly ^[4]. The content never leaves your systems. The first 2,000 witnesses a month are free.

How it would work

1. The agent receives an instruction and calls a tool.
2. Your system seals a record of the instruction, the tool call and the result.
3. When the action is questioned, you share the record and anyone can check it against the seal.

What this means for you

If your organisation uses AI agents, here are three questions to ask this week:

• Could we show what our agents did on a given day, in a way someone outside the organisation could check?
• Who has access to the logs, and could someone with that access quietly edit them?
• If an agent acts on someone's credentials and the outcome is questioned, whose problem is it?

The liability question in the Trellix survey is worth taking seriously ^[1]. When agents act with employee credentials, the lines between what the agent did and what the person is responsible for start to blur. A clear, checkable log of what happened helps settle those questions before they become disputes.

What to watch

The AI Act's logging requirements for high-risk systems start on 2 December 2027 for Annex III systems ^[2]. If you are building or using agents in high-risk areas, the clock has started.

For financial firms, DORA's log protection requirements are already in force ^[3]. Expect supervisors to ask about them in the next round of audits.

And if you are a CISO worrying about liability, you are not alone. The 600 others in the survey are thinking about the same thing ^[1].