Secure every MCP tool call before the agent reaches it

Article 12 requires high-risk AI systems to technically allow automatic event logging over the system lifetime. Bindfort is positioned to provide the MCP tool-call side of that record: caller, tool, server identity, policy decision, timestamped result, and receipt evidence.

Annex IV is about technical documentation. Bindfort does not make a system compliant by itself, but its receipts, dependency findings, policy records, and server fingerprints are the kind of structured evidence EU operators need for audit files and design-partner reviews ahead of the 2 August 2026 AI Act milestone.

The local verification path can generate a verifier-backed evidence bundle from receipt logs withbindfort evidence bundle.

Agent security evidence should not require exporting sensitive tool inputs, internal system names, or audit trails to another jurisdiction. Bindfort is designed for self-hosted deployment, EU-controlled evidence retention, and Poland-based EU market positioning from the start.

In the current verification path, the local demo writes receipt evidence with HMAC and server fingerprint fields. The bindfort verify receipts.jsonl command recomputes the HMAC chain from a signing key kept outside the log, exits non-zero on tampering, and reports the receipt that failed.

The verifier is a shipped CLI command in the local verification path. The remaining launch work is external pilot validation and production-grade install artifacts around it.

After verification, bindfort evidence bundle writes a local manifest, Article map, and operator README without copying raw receipt logs by default.

It is ready for a guided technical walkthrough and design-partner evaluation. The verified path currently covers config validation, build, tests, policy allow/deny behavior, and receipt evidence.

It is not yet a self-serve production product. First-user packaging and operator docs now exist as a guided path; the remaining launch work is one real pilot environment, release artifacts, and production operations packaging.

A first evaluation should show that Bindfort can sit between an agent and an MCP server, enforce a deny rule before the tool call reaches the server, allow known-safe calls, and produce audit evidence that can be reviewed after the run.

Routing gateways forward MCP traffic and usually focus on auth, rate limits, and transport. Bindfort focuses on security evidence before and after the call: installed dependency risk, policy decision, tool-call outcome, and receipt records.

Today, a guided evaluation can show scanner findings, policy decisions, and receipt verification for a controlled MCP server path. Bindfort is not yet a packaged self-serve production CVE response system.

Live blocking, alert routing, affected-tool reporting, and exception review are v1.0 roadmap items, not shipped behavior on the current page.

That is the intended deployment posture for design partners: keep agent traffic, tool-call evidence, and audit records under the operator's control instead of requiring sensitive traces to leave the environment.

Bindfort is not claiming SOC 2 certification today. The current value is that policy decisions, receipt records, scanner findings, and server fingerprints can support future control evidence for audits.

Formal SOC 2 mapping, auditor-ready exports, and control evidence workflows are v1.0 roadmap work. Self-hosting helps with data control, but it does not remove the buyer's audit obligations.

Roadmap work includes air-gapped packaging, offline vulnerability data updates, signed update flow, documented gateway-adapter patterns, and broader compatibility testing across transports.