{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihvwmxityyvbaelcka3vmd2hpjsyxzis5grgylxsmfelgpecvzmsa",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3moprpe6pkpl2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreigmbqqa7wewnw6v4avw3ql4ydic3fzmfi72axyptts2gk66ym7awy"
    },
    "mimeType": "image/webp",
    "size": 90718
  },
  "path": "/sentinelsca/i-spent-6-months-building-a-runtime-governance-layer-for-ai-agents-heres-what-survived-testing-54gf",
  "publishedAt": "2026-06-20T11:22:29.000Z",
  "site": "https://dev.to",
  "tags": [
    "agents",
    "ai",
    "security",
    "showdev",
    "https://sentinelsca.com",
    "https://sentinelsca.com/docs",
    "https://sentinelsca.com/docs/validation-report",
    "https://github.com/sentinelSCA/sentinel"
  ],
  "textContent": "Agents are moving from demos to touching money, infrastructure, and customer data.\n\nSentinel SCA is a runtime admissibility layer. Before an agent action executes, Sentinel evaluates the request and returns one of three verdicts:\n\n  * ALLOW\n  * REVIEW\n  * DENY\n\n\n\nEvery decision is cryptographically signed and recorded in a tamper-evident audit ledger.\n\nThis post is the validation report: what I built, what I tested, what passed, and what remains unproven.\n\nAt the time of writing, Sentinel has been validated across:\n\n  * 1,400+ signed governance decisions\n  * 100% signature verification in validation runs\n  * Replay attack testing under concurrency\n  * Decision consistency testing\n  * Reputation adaptation testing\n  * Evidence bundle generation and SIEM export validation\n\n\n\nI’m a solo founder. I spent six months building Sentinel and then trying to break it.\n\nThis is the part most AI project posts skip: the testing.\n\nIf you’re building agents that do anything consequential, I think the problem I ran into is about to become your problem too.\n\nThe Problem Isn’t Capability. It’s Admissibility.\n\nMost agent-safety conversations focus on capabilities:\n\nWhat can an agent do?\n\nCapabilities matter, but they are only part of the story.\n\nCapabilities are static.\n\nAdmissibility is contextual.\n\nA capability only says an agent may attempt an action. It says nothing about whether that action should execute right now.\n\nConsider:\n\nFinancial Example\n\nCapability:\n\ntransfer_funds\n\nScenario A:\n\n  * Transfer $40\n  * Known internal destination\n  * Agent with clean history\n\n\n\nProbably admissible.\n\nScenario B:\n\n  * Transfer $400,000\n  * Unknown destination\n  * Agent failed ten governance checks this morning\n\n\n\nProbably not admissible.\n\nSame capability.\n\nDifferent admissibility.\n\nInfrastructure Example\n\nCapability:\n\nrestart_service\n\nScenario A:\n\n  * Restart staging service\n  * During maintenance window\n\n\n\nProbably admissible.\n\nScenario B:\n\n  * Restart production database cluster\n  * During peak customer traffic\n\n\n\nProbably not admissible.\n\nAgain:\n\nSame capability.\n\nDifferent admissibility.\n\nThe decision cannot live in the permission grant.\n\nIt has to be made at execution time, with context.\n\nThat is the gap Sentinel sits in.\n\nWhat Is Sentinel SCA?\n\nSentinel is a runtime governance layer for autonomous systems.\n\nIt sits between an agent and an execution boundary.\n\nFor every proposed action:\n\nAgent proposes action\n\n↓\n\nSentinel evaluates admissibility\n\n↓\n\nALLOW / REVIEW / DENY\n\n↓\n\nDecision signed\n\n↓\n\nAudit ledger\n\n↓\n\nEvidence export / SIEM\n\nThe design principle I held throughout development was simple:\n\nSentinel decides what may execute.\n\nThe customer decides what their agent should be able to attempt.\n\nCustomers own:\n\n  * Agents\n  * Capabilities\n  * Policies\n  * Reviewers\n\n\n\nSentinel governs execution.\n\nIt does not own the agent.\n\nThe Governance Pipeline\n\nEvery action passes through multiple governance layers.\n\n  1. Identity Verification\n\n\n\nEvery request is signed using Ed25519.\n\nUnknown, suspended, or improperly signed agents receive no execution authority.\n\n  1. Freshness, Replay Defense, and Idempotency\n\n\n\nTimestamp windows, nonce validation, replay detection, and idempotency controls prevent old authority from being reused.\n\n  1. Capability Enforcement\n\n\n\nThe agent must possess the capability being attempted.\n\nMissing capability:\n\nDENY.\n\n  1. Schema Validation\n\n\n\nActions must conform to expected structures.\n\nMalformed requests never reach execution.\n\n  1. Operational Controls\n\n\n\nGlobal freezes, kill switches, and rate limits can halt activity regardless of agent status.\n\n  1. Deterministic Policy Evaluation\n\n\n\nThe same canonical action should always produce the same governance result.\n\n  1. Risk Assessment\n\n\n\nRisk scoring considers:\n\n  * Action type\n  * Notional value\n  * Frequency\n  * Context\n\n\n  1. History-Based Trust Signal\n\n\n\nAgent behavior influences future admissibility decisions.\n\nGood behavior builds trust.\n\nUnsafe behavior reduces it.\n\n  1. Verdict\n\n\n\nSentinel returns:\n\n  * ALLOW\n  * REVIEW\n  * DENY\n\n\n\nThe decision is then:\n\n  * Signed\n  * Recorded\n  * Auditable\n\n\n\nValidation Results\n\nAnyone can describe a system.\n\nFewer people publish test results.\n\n  1. Verdicts Scale With Consequence\n\n\n\nGovernance is graded.\n\nNot binary.\n\nAction Verdict\nRead-only health check ALLOW\nSmall approved trade ALLOW\nLarge trade REVIEW\nFunds transfer REVIEW\nFunds transfer above limit DENY\nDeploy to staging REVIEW\nMissing capability DENY\n\nAn important clarification:\n\nMissing capability DENY results are enforcement decisions.\n\nThey are not false positives.\n\nFor actions with valid capabilities, the false-positive rate in this validation run was zero.\n\n  1. Replay Protection Holds Under Concurrency\n\n\n\nI fired one signed request thirty times simultaneously.\n\nResult:\n\n  * Executed: 1\n  * Rejected: 29\n\n\n\nExactly-once behavior held under concurrent load.\n\nFor financial or infrastructure actions, this property is non-negotiable.\n\n  1. Identical Actions Produce Identical Decisions\n\n\n\nThe same canonical action was executed repeatedly.\n\nResults:\n\n  * Same verdict every time\n  * No decision drift\n  * Valid signatures on every response\n\n\n\nEquivalent inputs produced equivalent outputs.\n\n  1. Reputation Moves In The Right Direction\n\n\n\nThis was one of the tests I most wanted to fail honestly.\n\nFresh agent.\n\n60 actions.\n\nPhase 1\n\nSafe actions:\n\n  * Reads\n  * Small trades\n\n\n\nResult:\n\nReputation increased steadily.\n\nPhase 2\n\nRisky actions:\n\n  * Large transfers\n  * Destructive operations\n\n\n\nResult:\n\nReputation decreased steadily.\n\nThis is reported as observed validation behavior, not a universal guarantee.\n\nHowever, the signal behaved correctly:\n\nGood behavior increased trust.\n\nBad behavior reduced it.\n\n  1. Reviews Resolve Even When Nobody Is Watching\n\n\n\nA REVIEW cannot remain unresolved forever.\n\nOtherwise governance becomes a denial-of-service against itself.\n\nReview resolution follows risk bands:\n\nLow Risk\n\nAutomatically approved after timeout.\n\nMedium Risk\n\nEscalated to the customer reviewer.\n\nIf unanswered:\n\nFail closed.\n\nHigh Risk\n\nAutomatically denied.\n\nA background worker finalizes unresolved reviews.\n\nNo dashboard needs to remain open.\n\nNo action remains stuck forever.\n\nNo race condition can double-decide an action.\n\nFor obvious reasons, exact thresholds are intentionally not published.\n\n  1. Cryptographic Auditability\n\n\n\nEvery decision contains:\n\n  * Ed25519 signature\n  * Deterministic action hash\n  * Policy version\n  * Key identifier\n\n\n\nRecords are hash-linked into an append-only chain.\n\nValidation confirmed:\n\n  * Signature integrity\n  * Chain continuity\n  * Independent verification\n\n\n\nEvidence bundles and SIEM exports are generated for downstream audit systems.\n\nWhat Sentinel Does Not Solve\n\nThis section matters.\n\nEvery security system has boundaries.\n\nSentinel does not:\n\n  * Prevent model jailbreaks by itself\n  * Replace application authorization\n  * Eliminate insider abuse\n  * Remove the need for secure key management\n  * Guarantee model correctness\n\n\n\nSentinel is a runtime governor.\n\nIt governs execution authority.\n\nIt is not a replacement for every other security control.\n\nWhat I’m Not Claiming\n\nI want this section to be explicit.\n\nProduction-Ready Does Not Mean Finished\n\nThe core governance boundary is coherent and testable.\n\nThe product is still evolving.\n\nLong-Duration Soak Testing\n\nNot yet completed.\n\nIndependent Security Review\n\nNot yet completed.\n\nI want:\n\n  * External penetration testing\n  * Independent cryptographic review\n\n\n\nAvailability\n\n99.9% is a target.\n\nIt is not yet measured historical uptime.\n\nPerformance\n\nLatency and throughput numbers are observed validation results.\n\nThey are not contractual guarantees.\n\nEnterprise Features\n\nSome enterprise features remain roadmap items:\n\n  * SSO / SAML\n  * HSM-backed identity\n  * Private VPC deployments\n  * Multi-region deployments\n\n\n\nEarly Audit Records\n\nA small number of early audit records predate persistence of the exact canonical signing payload.\n\nThey remain chain-verifiable but cannot support standalone signature verification.\n\nI’d rather disclose that than hide it.\n\nWhy This Matters\n\nThe industry is getting very good at making agents capable.\n\nWe spend far less effort making their actions:\n\n  * Bounded\n  * Attributable\n  * Governed\n  * Auditable\n\n\n\nI don’t think the answer is to slow agents down.\n\nI think the answer is a thin layer between intent and execution.\n\nA layer that:\n\n  * Allows most actions\n  * Pauses when judgment is required\n  * Refuses when necessary\n  * Produces evidence afterward\n\n\n\nAnd can prove exactly what happened.\n\nThat’s the thesis behind Sentinel.\n\nChallenge The Model\n\nI’d rather hear:\n\n“Your replay test is weak because X.”\n\nthan:\n\n“Cool project.”\n\nIf you’re:\n\n  * A security engineer\n  * A compliance specialist\n  * An auditor\n  * An AI platform builder\n  * A red teamer\n\n\n\nTell me where this model breaks.\n\nQuestions I’m particularly interested in:\n\n  * How would you bypass admissibility?\n  * What evidence artifact is missing?\n  * What canonicalization edge cases am I ignoring?\n  * Where does this governance model fail under real-world pressure?\n\n\n\nThe fastest way to improve governance infrastructure is to expose it to people whose job is to challenge assumptions.\n\nIf you see a flaw, point it out.\n\nThat’s how Sentinel gets better.\n\nWebsite: https://sentinelsca.com\n\nDocumentation: https://sentinelsca.com/docs\n\nValidation Report: https://sentinelsca.com/docs/validation-report\n\nGitHub: [https://github.com/sentinelSCA/sentinel]\n\n— Building Sentinel SCA, solo, and testing it in the open.",
  "title": "I spent 6 months building a runtime governance layer for AI agents — here's what survived testing\""
}