AI Can Act. Accountability Has to Keep Up.

I worry we're becoming too comfortable calling an AI agent secure because it gives a sensible answer. I want to know what it does when it has access to tools.

An agent can send data, edit a record, or submit a payment request. The action it takes may matter far more than the message it returns to the user. A good answer doesn't tell us whether the tool call stayed within the task that person authorized.

For years, security teams have built controls around identities, applications, and networks. Those controls still matter. But valid credentials alone cannot tell an operator whether a particular action was the one the user intended. That gap is why we started working on agent integrity at Cogensec.

Consider a hypothetical finance agent asked to read invoices and prepare a payment batch. It signs in to an approved service and calls the correct payment API. The request succeeds.

Now suppose the destination account in the request differs from the account in the approved vendor record. The team needs to reconstruct what happened. Which invoice did the agent read? What instructions did it receive? What account did it send to the payment tool, and who approved the change?

An API success response won't answer those questions. A useful execution record would connect the task, the relevant data, the tool arguments, the actual action, and any approval step. It also needs to protect sensitive information in those records.

Identity and access management can establish who was allowed to call the API. We also need a way to examine whether the call matched the authority delegated to the agent.

Agentegrity is our open-source work on agent integrity during execution. We are developing ways to assess behavior, preserve governance evidence, and support recovery when something goes wrong. An integrity assessment should be tied to observable events and its known limitations. A score without that context tells an operator very little.

Aversyn focuses on authorized adversarial testing. We want a security team to be able to examine how a finding was produced: the task, test conditions, observed actions, and result. A finding should distinguish what an agent attempted from what it actually completed. We are still building out that work.

Our Human Control research asks how an organization can interrupt, correct, or revoke an agent's authority when conditions change. These questions reach into policy design, tool permissions, and recovery. Some of the work remains research rather than a product capability.

We want to publish the methods behind our claims, including failed tests and limits on what we can conclude. If a capability is experimental, readers should see that before they make decisions based on it. Our research pages are where those methods and findings belong.

Developers need to inspect which tools an agent called, what arguments it supplied, and what the tools returned. They should be able to see where the agent crossed an approval boundary without exposing customer data unnecessarily.

A security team reviewing a test needs the conditions under which it ran. Was an unsafe action proposed, attempted, or completed? Which control responded? Could another reviewer reproduce the finding?

The person approving deployment has a different set of questions. Who can stop the agent? What happens if its permissions change? When should it be tested again? A workflow that passed a test last month may behave differently after its model, tools, or access rights change.

These questions affect anyone whose information sits behind those tools. An automated request to disclose a customer record still needs the right authority, and an organization needs a record of how that request was handled.

Give an agent a harmless task with an explicit boundary. Watch its tool calls. Then ask someone who did not run the test to reconstruct the agent's actions from the available records. Change one condition, such as tool access, and run the test again.

You'll find out quickly which parts of the workflow are observable, which decisions are difficult to explain, and where a person can intervene. Those are concrete gaps a team can work on before granting the agent more authority.

If you're wrestling with those questions in a real deployment,talk with our team. I'd welcome the chance to compare what you're seeing with what we're studying at Cogensec.