A AEP AI AGENT EVIDENCE
Accountability for AI agents, backed by proof

Everything you hand to AI, provable after the fact.

AEP keeps what your agents saw, what they decided and who approved it as proof that cannot be rewritten later. When an audit or an incident review comes, you can show the original grounds.

EVIDENCE TRAIL Verifiable
External information retrieved09:41

Source, content and time fixed together

A decision made on it09:42

Referenced proof and applied rules tied to the decision

An owner approves09:43

Recorded only as an explicit action by that person

No tampering Source matches Time verified Undetermined items kept separate

Connection: MCP + OAuth. Your existing agent calls AEP within the signed-in organisation and the scopes you granted. No rework on the agent side.

Fix what was seen, on the spot

Pages and data change later. The content as retrieved is kept together with its source and time.

Tie decisions to approvals

Which information, which rules, and who approved it are bound to the decision itself.

Anyone can check it later

Proof is stored so tampering is detectable, and auditors or partners can confirm authenticity.

01 / The problem

Logs remain. Evidence does not.

If you cannot show that things really were that way at the time, a log is not material for an explanation. The more autonomously agents act, the more that gap matters.

01
The information referenced changes

Prices, stock, contract terms, news. The page an agent read can be replaced. Without the content as retrieved, you cannot show the decision was sound.

Fix source and content together, never apart.
02
The reasons cannot be reconstructed

An outcome alone does not tell you which inputs and which rules produced it. When asked to explain, you need the inputs as they stood.

Fix the decision and its input set at once.
03
Who approved becomes unclear

It gets disputed as time passes. Approval should be kept only as an explicit action by an authorised person.

Never infer approval from another request.
02 / Capabilities

Seven kinds of proof that prevent AI incidents

Each answers a different question. Click a row to see what is proven and which incident it prevents.

What is proven

The source, a fingerprint of the response, the time of retrieval and which agent's task it belonged to are bound into one proof. Whether the proof is bound to its origin or merely sealed locally is kept distinct.

Incidents prevented

Substitution of a different page or response, claims about information never seen, and being unable to identify which response was involved in an incident.

What this does and does not establish

The existence of proof does not mean the decision was right. Whether a source was factual, whether the rules were appropriate, and whether a decision or approval was sound all require separate judgement. What AEP provides is the ability to prove, afterwards, the grounds, time, participants and configuration of the moment.

03 / Getting started

Sign up and you are running

STEP 01
Sign up

Register with an email address and an environment for your organisation is created on the spot.

STEP 02
Choose a plan

Pick one to match how much proof you keep. You can change it later.

STEP 03
Connect your agent

Set the issued connection details and your existing agent can call AEP.

STEP 04
Check when needed

When an explanation or investigation is required, confirm authenticity and time from the console.

04 / Who uses it

For every team running AI agents

It is the weight of what you delegate, not your industry, that makes this necessary.

Security

Confirm that an agent's blocks and allowances rested on sufficiently fresh information, and trace which information led to a decision during an incident.

IT operations

Bind prompts, rules, model references and permissions into one version, so you can identify which version was running when something goes wrong.

Agent engineering

Record whether connected tools changed without notice, and catch planted instructions or dangerous new parameters.

Process automation

For high-impact actions such as payments, publishing and granting access, keep a record of who approved what.

05 / Safety

The proof mechanism itself is designed conservatively

Whether proof is trusted depends on how it is gathered and handled. Scope, secrecy and the treatment of undetermined results are constrained from the start.

Operates only within granted scope

Use is limited to the signed-in organisation and the permissions granted. Nothing outside that scope is collected or published.

Credentials never enter proof

Passwords, one-time codes, API keys and access tokens are never included in proof or in notifications.

Results are not rounded off

Verified, not verified and undetermined are returned as distinct states. An undetermined result is never treated as valid.

Approval only as a personal act

Approval is never inferred from another request. Only an explicit instruction from an authorised person is kept as an approval.

06 / FAQ

Frequently asked questions

Lay the groundwork before you delegate more.

COMING SOONComing soon← Packet Pilot Products