SENTINEL · Compliance
How SENTINEL's design maps to the emerging regulatory requirements for autonomous agents — and, precisely, where the obligation falls.
A regulatory consensus formed in 2026 around a single demand: autonomous agent activity must leave a verifiable, tamper-evident, after-the-fact-auditable trail. SENTINEL produces exactly that trail as a native output — not as a reporting layer added afterward.
This page maps SENTINEL's capabilities to the concrete requirements of the frameworks now in force. It is an engineering reference for compliance readiness, not legal advice, and — importantly — it does not claim that SENTINEL "makes an agent compliant." No third-party service can. What SENTINEL supplies is the verifiable evidentiary substrate that compliance with these frameworks requires. The accountability remains with the deploying organization and the human overseer. That distinction is stated plainly throughout, because overclaiming it would defeat the purpose.
Every framework below places ultimate accountability on the deploying organization and a named human overseer, not on any protocol or vendor. Singapore's IMDA framework is explicit that humans must remain meaningfully accountable regardless of the degree of autonomy; the EU AI Act's oversight and record-keeping duties fall on the provider and deployer. SENTINEL discharges none of these duties on anyone's behalf.
What an organization subject to these obligations needs is a source of record that is durable, verifiable, and independent — so that when it must show why an agent was permitted or refused a transaction, and prove that decision rested on a real, contemporaneous, tamper-evident assessment, it has the evidence to do so. That is the role SENTINEL fills.
The first government-issued framework for agentic AI, structured around four dimensions: bounding risk, meaningful human accountability, technical controls, and end-user responsibility. Its technical-controls dimension calls for comprehensive logging and audit trails for all agent decisions and actions, to support after-the-fact review, plus incident-management protocols for autonomous-system failure modes.
| IMDA requirement | SENTINEL capability |
|---|---|
| Comprehensive logging and audit trail for after-the-fact review | The append-only Default Registry: a tamper-evident, hash-anchored log of every verified counterparty incident, permanently inspectable |
| Incident-management protocol for agent failure modes | A structured incident taxonomy (non-payment, replay abuse, non-delivery, quality fraud) with each incident recorded as immutable evidence |
| Documented basis for trust/oversight decisions | Signed ES256 attestations: for each decision, a verifiable, timestamped record of what the trust judgment was and when it was made |
| Technical controls that scale with risk | meetsThreshold on-chain and configurable score gates let oversight be proportional — strict for high-value transactions, permissive for low |
Article 12 requires high-risk AI systems to technically allow the automatic recording of events (logs) over the system's lifetime, at a level of traceability appropriate to purpose. Regulators interpret "appropriate" as tamper-evident: an audit trail whose entries cannot be silently altered or deleted. Article 19 requires those logs be retained for at least six months. Article 13 requires that operation be transparent enough for a deployer to interpret and use the output.
| EU AI Act requirement | SENTINEL capability |
|---|---|
| Art. 12 — automatic, tamper-evident event logging | The Default Registry is append-only and hash-anchored, with immutability enforced at the database layer (triggers), not by policy — tamper-evidence by construction |
| Art. 12 — traceability appropriate to purpose | Each score is reconstructable from anchored evidence via the published methodology; a judgment can be recomputed and traced to the specific incidents behind it |
| Art. 13 — transparency and interpretability of output | The public methodology means no score is a black box: an auditor can see exactly how any judgment was reached |
| Art. 19 — log retention | Append-only records persist by design; nothing is deleted |
NIST's initiative names the structural gap directly: agents are commonly treated as generic service accounts without dedicated identity, authorization, or accountability controls. Its focus areas include agent identity/authentication, action logging and auditability, and containment boundaries.
| NIST focus area | SENTINEL capability |
|---|---|
| Agent identity / authentication | SENTINEL scores are keyed to on-chain identities (wallet / ERC-8004 agentId); attestations are cryptographically signed and bound to a subject |
| Action logging and auditability | The Default Registry and signed attestations constitute an independent, auditable log of counterparty risk decisions |
| Accountability beyond shared service accounts | Bidirectional scoring assesses a specific counterparty as payer or seller — not an anonymous shared account |
Off-the-shelf AI systems, including widely used APIs, generate outputs but do not produce tamper-evident, reconstructable records by default. That is the structural gap these frameworks expose: organizations discover, late, that their systems can act but cannot prove how they acted.
SENTINEL was built the other way around. The audit trail is not a feature bolted on for a compliance questionnaire; it is the system's native output, because the same property that makes a trust signal trustworthy — verifiable, immutable, recomputable evidence — is the property these regulations require. Building trust correctly and building it to be auditable turn out to be the same task. That equivalence is the subject of our whitepaper, Recomputable Trust.
SENTINEL does not make an agent compliant, does not discharge any organization's accountability, and is not a substitute for legal counsel on any of these frameworks. It supplies verifiable, tamper-evident evidence of counterparty trust decisions — the substrate on which an organization's own compliance can rest. Used that way, it turns a requirement that many systems meet late and under pressure into a property that is present by default.
This page is an engineering reference for compliance readiness, not legal advice; consult the official regulation texts and qualified counsel for authoritative interpretation. SENTINEL is live at sentinel-agent.dev. Methodology: /methodology. Whitepaper: /whitepaper.