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.
Source, content and time fixed together
Referenced proof and applied rules tied to the decision
Recorded only as an explicit action by that person
Connection: MCP + OAuth. Your existing agent calls AEP within the signed-in organisation and the scopes you granted. No rework on the agent side.
Pages and data change later. The content as retrieved is kept together with its source and time.
Which information, which rules, and who approved it are bound to the decision itself.
Proof is stored so tampering is detectable, and auditors or partners can confirm authenticity.
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.
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.
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.
It gets disputed as time passes. Approval should be kept only as an explicit action by an authorised person.
Each answers a different question. Click a row to see what is proven and which incident it prevents.
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.
Substitution of a different page or response, claims about information never seen, and being unable to identify which response was involved in an incident.
Both proofs, their fingerprints, the normalisation used for comparison and the concrete differences are collected in one record. Missing content is never filled in by guesswork.
Missing a significant change, continuing on outdated terms or specifications, and having before and after swapped after an incident.
A trusted time, the verification state of that time, the moment of evaluation, the allowed age and the tolerated forward skew determine whether the information was usable.
Acting on expired stock or stale threat data, trusting an unverified time, and ignoring per-purpose expiry.
The proofs referenced, the rule evaluation, the risk class and a fingerprint of the outcome are bound together, fixing the inputs as of the decision. The reasoning process itself is not stored.
Swapping the grounds afterwards, acting without the required proof, and losing the ability to explain which input led to the result.
The identity of the endpoint, the protocol version, a normalised list of the tools offered, and the relation to the previous proof are kept.
Instructions planted in tool descriptions, dangerous new parameters, and silent changes behind an unchanged tool name.
Names, fingerprints, sizes and types of prompts, rules, model references, connected tools, permissions and evaluation results are bound into one release.
Shipping unapproved prompts or rules, confusing a test build with production, losing the relevant version during an incident, and reusing a version name.
The authenticated approver, fingerprints of the action and the policy, the related decision proof, and the approve-or-reject outcome are bound together.
Acting without approval, substituting a different action after approval, and later confusion or denial about who permitted what.
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.
Register with an email address and an environment for your organisation is created on the spot.
Pick one to match how much proof you keep. You can change it later.
Set the issued connection details and your existing agent can call AEP.
When an explanation or investigation is required, confirm authenticity and time from the console.
It is the weight of what you delegate, not your industry, that makes this necessary.
Confirm that an agent's blocks and allowances rested on sufficiently fresh information, and trace which information led to a decision during an incident.
Bind prompts, rules, model references and permissions into one version, so you can identify which version was running when something goes wrong.
Record whether connected tools changed without notice, and catch planted instructions or dangerous new parameters.
For high-impact actions such as payments, publishing and granting access, keep a record of who approved what.
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.
Use is limited to the signed-in organisation and the permissions granted. Nothing outside that scope is collected or published.
Passwords, one-time codes, API keys and access tokens are never included in proof or in notifications.
Verified, not verified and undetermined are returned as distinct states. An undetermined result is never treated as valid.
Approval is never inferred from another request. Only an explicit instruction from an authorised person is kept as an approval.
Yes. Your agent calls AEP within the granted scope. No rework of the agent is required.
Signing up with an email address and choosing a plan. There is no sales process and no prior screening.
The signed-in organisation, within the permissions granted. Authenticity can be confirmed afterwards by authorised staff or a third party.
No. Proof lets you confirm the grounds, time, participants and configuration of the moment. Whether the source was factual and whether the rules or the decision were sound must be judged separately.
No. Passwords, one-time codes, API keys and access tokens are excluded from proof and notifications by design.