Socure wants to tie *every AI agent* to a verified person or business

The agent problem nobody saw coming

AI agents are already booking flights, handling customer queries and moving money between accounts. The question nobody has a good answer to yet is: who asked them to?

When a chatbot books you on the wrong flight and you ring the airline, the person at the other end needs to know whether you authorised the agent or someone else did. It's the difference between fixing a mistake and investigating fraud.

Socure's answer, launched this week, is Agent Intelligence: a platform in three parts that spots agents, scores them and ties each one to a verified person or business. ^[1]

Three layers, one problem

Agent Detection works like a spam filter for bots. It spots AI agents in real time and is generally available now. Agent TrustScore, currently in beta, rates each agent on trustworthiness: how it behaves, who authorised it and whether it has been flagged before. Agent Credential, launching in Q1 2027, is where the real control sits. It binds an agent to a verified identity, and it can be revoked. ^[1]

Think of it like a staff pass. The pass says who you are and who you work for, and if you leave the building it gets deactivated. An agent with a credential carries a machine-readable signal saying this agent was authorised by this verified person or business, and the organisation on the other end can check that signal before letting the agent act.

The transparency gap

The AI Act already requires people to be told when they are interacting with an AI system, and that applies from 2 August 2026. ^[2] It doesn't say how to tell them, just that it has to happen. A marking on agent-generated messages could meet that duty, and Socure's credential proposal goes further: it says who stands behind the agent.

That's useful when things go sideways. If an agent places an order nobody wanted, the seller needs to know whether to treat it as a mistake or a scam. A credential that points to a verified person or business gives them something to work with.

What it doesn't solve

A credential shows who authorised the agent, not whether the agent was right to do what it did. If the agent books you on the wrong flight because you asked for Tuesday and it heard Thursday, the credential won't settle whose fault that is.

It also doesn't replace logging. When a dispute turns on what the agent actually said or did, you still need a record of the instruction, the action and the result. That's where Article 12 comes in for high-risk AI systems: they must technically allow for the automatic recording of events over their lifetime, and for Annex III systems that applies from 2 December 2027. ^[3] Article 12 says what to log, not how to protect the logs, but protecting them is still a good idea for a simple reason: one day someone will ask you to prove what your system did.

Sealing what the agent did

Say an agent changes a customer's order and the customer says nobody asked it to. The agent's logs should show the instruction, the tool call and the result. The question is whether anyone can trust those logs months later, when the people who keep them could also have changed them.

Here, the thing to seal is each instruction, tool call and result as the agent acts. Sealing takes a fingerprint of the record, not the content, so the action log itself never leaves your systems. When it's questioned, anyone you share the record with can calculate the fingerprint again and check that it matches. Change a single character in the log and it won't match.

How it would work

1. Your agent platform sends a fingerprint of each action record to WitniumChain through the MCP server and gets a witness ID back.
2. The log stays with you, unchanged.
3. When someone questions an action, you share the record and the witness ID. They check the fingerprint against the sealed one.

Anyone can do the check, whether it's your own audit team, the customer or a regulator. The witness shows that the record is exactly what was logged at that time. It doesn't authorise the action or make it correct, and it doesn't replace oversight or controls.

You can start with the REST API, the SDK or the MCP server, the content stays with you, and the first 2,000 witnesses a month are free.

What this means for you

If you are building or running AI agents, here are three questions worth asking this week:

• How would we show who authorised an agent to act on their behalf?
• If a customer disputes what an agent did, whose record of the action would we rely on?
• Could we demonstrate to an auditor or a supervisor that our agent logs haven't been edited after the fact?

Socure's credential proposal tackles the first question. The second and third are logging questions, and sealing gives you a way to answer them without anyone having to trust whoever keeps the log.

What to watch

The AI Act's transparency requirement in Article 50 applies from 2 August 2026. For high-risk AI systems under Annex III, the logging duty in Article 12 applies from 2 December 2027, and user duties including informing people affected by decisions apply from the same date. ^{[3] [4]}

Sources

^[1] Socure Unveils Agent Intelligence to Tackle AI Agent Fraud, Help Net Security, 27 October 2026, https://www.helpnetsecurity.com/2026/10/27/socure-agent-intelligence/

^[2] Article 50 of Regulation (EU) 2024/1689, AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50

^[3] Article 12 of Regulation (EU) 2024/1689, AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12

^[4] Article 26 of Regulation (EU) 2024/1689, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2024/1689/oj