Watch demo

_{Badges point to repository evidence.}

How Attestor connects to existing systems

Control infrastructure for high-risk AI-driven operations.

Attestor sits between an AI-prepared operation and the system that would execute it. Prompts can guide behavior, but they cannot enforce it or stop an unsafe, unauthorized, or out-of-scope service call.

Unsafe requests can come from hallucination, stale context, poisoned tool output, replay, missing approval, or hostile content. Before anything runs, Attestor checks policy, authority, scope, freshness, replay, and evidence, then returns admit, narrow, review, or block.

The customer-owned gate decides before execution. The trail records what was proposed, what was checked, and why it was held or allowed.

Why This Matters Now

AI systems are moving from chat into tools that can touch payments, data, access, customer messages, infrastructure, and programmable money.

That is no longer a prompt-quality problem. Teams need a stop point before execution, and a record after review: who asked, what was checked, why it held or blocked, and what may run next.

Context anchors: EU AI Act, NIST AI Risk Management Framework, and DORA. These are not compliance claims.

What It Does

Attestor translates AI intent into a structured consequence, then reduces it to a decision, gate status, and proof references.

It checks policy, approval, evidence, allowed scope, freshness, replay, tenant, and token, then returns one bounded decision with reasons: admit, narrow, review, or block.

For requestable approvals, it checks that the approved task still matches the current policy and material scope context before execution.

The real service should run only through the customer-owned gate.

System metadata can show where risky actions are forming. Existing APIs, tools, jobs, telemetry, events, and gateway logs can become review material for action discovery, rule drafts, admission decisions, customer gates, and proof.

View the full consequence path map

AI agent
  -> proposes an operation
Attestor
  -> admit / narrow / review / block + reasons and proof references
Customer-owned gate
  -> calls the real service only when allowed

Without a customer-side gate, the decision is evidence, not enforcement. With that downstream point, it becomes the stop point.

Run Attestor in shadow pilot mode

Observe mode shows what actions agents would try, why they may be risky, and which policy, approval, and evidence are present. You see the risk before a real service runs.

Run Attestor in shadow pilot mode

The Same Pattern Across Operations

The same gate can sit before these operation classes:

Current State

Package version: 0.3.0-evaluation
Release tag:     v0.3.0-evaluation
Release stage:   evaluation baseline
Release type:    repository baseline / multi-path local review

This baseline is for local review and integration planning. Live customer deployment and external security audit are separate proof steps.

Data Posture

Attestor is a control point, not a data lake. It needs structured request context and proof references, not raw customer data. Customer systems keep the model, agent, workflow, wallet, database, service call, and system of record.

Security and data handling

Start Here

Start light. Go deeper only when you need the detail. If you are new, follow this order: local run, shadow pilot, then customer gate.

• Try Attestor first - run the smallest local refund path and see the decision trail.
• Run Attestor in shadow pilot mode - observe one real action path before enforcing anything.
• How to integrate Attestor - find the real side effect and place the customer-owned gate.
• Repository navigator - find deeper docs for hosted, pricing, support, proof, or maintainer work.

Use boundaries: License and use and Security Policy.