The uninstrumented path is the assurance problem
A package can be installed while the real executor bypasses it. A framework upgrade can move the dispatch point. A new tool route can appear after certification. A healthy gateway does not prove that every local action traverses it.
Production-readiness certification answers whether a known integration and release passed its required tests. Runtime-coverage verification answers whether declared protection points are present, live and free from known gaps in the currently observed deployment.
AgenticDome uses signed, short-lived workload evidence rather than source uploads. The public SDK reports bounded hook identifiers and version/checksum metadata; proprietary analysis used to identify candidate interception points remains in private AgenticDome services.
What changes when AgenticDome is in the path
A registered workload signs a startup hook manifest containing its deployment/build identity, SDK and framework versions, expected hooks, observed hooks and designated high-impact actions. Fresh signed heartbeats reference that manifest and report active hooks. AgenticDome compares expected with observed, opens exact tenant-scoped gaps, and expires stale evidence rather than assuming continuing coverage.
Two assurance views, deliberately kept separate
Production readiness
A point-in-time certificate records that a tested release, configuration and required integration evidence passed.
Live hook health
Unexpired signed heartbeats show which registered workloads and declared hooks are actively reporting now.
Expected versus observed
Missing startup hooks and heartbeat gaps are named instead of being hidden inside a single optimistic status.
Release identity
Build, SDK, framework and manifest digests connect assurance to a particular deployment rather than a generic application name.
Coverage percentage is scoped evidence—not a universal claim
The denominator is the set of declared expected hooks for registered workloads. Unknown or invisible paths cannot be counted as protected. Discovery, architecture review, egress controls and negative testing remain necessary to find paths the application never declared.
How AgenticDome creates the control point
1. Register the workload
Bind a workload identifier to a tenant and an approved attestation public key; key rotation requires explicit control-plane approval.
2. Declare the release
Sign the deployment, build, SDK/framework metadata and expected/observed protection points at startup.
3. Prove continued presence
Send bounded, expiring heartbeats that reference the current signed manifest and active hooks.
4. Open exact gaps
Create a named missing-hook or missing-heartbeat gap when expected protection is absent or stale.
5. Apply fail-closed policy
Designated high-impact paths can require current protection evidence before the surrounding system permits execution.
What this changes for real teams
Detect framework drift
“A framework upgrade changed the executor and our old test still passes elsewhere.”
AgenticDome contribution: Release-bound manifests and active-hook comparison expose the missing declared protection point in the new deployment.
Separate tested from live
“A certificate should not imply that protection is still active months later.”
AgenticDome contribution: Readiness remains point-in-time evidence while expiring manifests and heartbeats provide a separate current-state result.
Investigate the exact gap
“A percentage alone does not tell the team what to fix.”
AgenticDome contribution: The tenant view names the workload, gap type and bounded protection-point label without uploading source code.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Installed but bypassed SDK | Imports or packages do not prove the authority-bearing executor traverses the control. | Compare expected and observed runtime hook identifiers and test the actual side-effect path. |
| Stale assurance | Old telemetry can remain green after a process stops reporting. | Expire manifests and heartbeats and open a gap when current signed evidence is absent. |
| Unapproved key replacement | An attacker could attempt to substitute workload evidence under a new key. | Bind each workload to an administrator-approved public-key fingerprint and require explicit rotation. |
| Unknown execution path | A path absent from the declared model cannot appear in the coverage denominator. | Treat runtime coverage as scoped evidence and retain architecture review, discovery and egress monitoring for unknown paths. |
A practical path to production
Map authority-bearing paths
Identify the routes that can change money, permissions, data, infrastructure or external state.
Protect attestation keys
Keep private keys with the workload and approve rotations through the control plane.
Set freshness expectations
Choose manifest and heartbeat expiry that detects drift without hiding normal deployment transitions.
Test bypasses
Exercise alternate routes, disabled hooks, framework upgrades and direct destination calls before claiming coverage.
Where this control ends
Runtime-coverage verification proves only signed evidence from registered workloads and configured gateways. It does not discover every possible code path, prove the correctness of a hook, replace penetration testing or guarantee that a destination honoured an allowed request. A 100% result means all currently declared protection points reported—not that invisible paths do not exist.
Current lifecycle note
Coverage must be regenerated for each materially different build, SDK/plugin version, framework version or execution topology. Evidence from a previous immutable release remains evidence for that release only.