DEV Community

correctover
correctover

Posted on

I built a 7-dimension runtime verification standard for AI agents

When you give an AI agent tools, you give it power. It can read files, call APIs, execute commands, access the network. The question is not whether it will be attacked. The question is whether you can prove what happened.

I spent the last few months building Correctover, a runtime authorization and evidence verification layer for AI agents. It intercepts tool calls before execution and scans tool outputs after execution. The core runs at P50 ~2.7 microseconds in Node.js with zero production dependencies.

But the code is not the interesting part. The interesting part is the standard behind it.

The 7 dimensions

CCS (Correctover Conformance Shape) is a 7-dimension runtime verification standard. Every tool call is evaluated along:

  1. Structure — does the output shape match the declared schema?
  2. Schema — do field values satisfy type and range constraints?
  3. Latency — did the call stay within its time budget?
  4. Cost — did it stay within token or spend limits?
  5. Identity — is the agent-tool binding what it claims to be?
  6. Integrity — is there an Ed25519-signed receipt with a hash chain?
  7. Security — does the call or output contain injection, SSRF, credential exfiltration, or destructive operations?

Each dimension is independently scorable. A deploy can enforce all seven, or only the ones relevant to its threat model. The standard is published as IETF Internet-Draft draft-correctover-ccs-05 (64 pages).

Why not just use a gateway?

Gateways sit in front of models. They see prompts and completions. They do not see the semantic boundary between an agent deciding to call a tool and the tool actually executing. That boundary is where: SSRF reaches 169.254.169.254, command injection reaches exec(), environment variables leak into tool output, and a tool returns prompt injection that the agent then trusts.

A gateway cannot distinguish a legitimate curl https://api.example.com from curl http://169.254.169.254/latest/meta-data/. It just sees text. CCS sees the call structure, the target, the arguments, and the output — at the point where the decision becomes an action.

Try it in 30 seconds

npx correctover-scan --demo
Enter fullscreen mode Exit fullscreen mode

This runs five sample MCP servers (four vulnerable, one clean) and reports CRITICAL/HIGH findings with remediation. No install, no signup, no configuration.

For a real project:

npm install correctover
Enter fullscreen mode Exit fullscreen mode

The package exports a guard that wraps any MCP tool handler. It supports an audit-only mode (log but do not block) for tuning rules against real traffic before enforcing.

What I need feedback on

  • False positives. If you run it against real MCP or DSH traffic and it flags something legitimate, that is the most valuable thing you can tell me.
  • Dimension coverage. Are the seven dimensions the right set? Is anything missing for your use case?
  • Integration friction. Where does it break against your framework?

The source is on Codeberg. The English landing page is here. Issues and PRs welcome.


Correctover is source-available (not MIT). The CCS specification itself is open via the IETF. Performance numbers are microbenchmarks; Node.js core verification P50 ~2.7us, Python end-to-end P50 ~27us. See the repository for methodology.

Top comments (0)