Hardware-enforced transaction validation with 6 rule types. Zero heap allocation in the evaluation path. Static dispatch for microsecond-scale policy checks.
Every transaction request from an AI agent passes through the Policy Engine before a signature is produced. The engine evaluates requests against a configurable set of rules that are loaded at enclave boot and cannot be modified at runtime without re-attestation.
The engine uses enum-based static dispatch (no vtable lookups, no heap allocation) to evaluate rules in the hot path. This keeps policy evaluation overhead to sub-microsecond levels.
The policy engine is implemented in Rust in the sentinel-policy crate. All rules are evaluated inline — no dynamic dispatch, no trait objects, no allocation in the evaluation path.
The engine supports 6 rule types, each targeting a specific risk vector:
Caps the maximum value of any single transaction. Prevents fat-finger errors and runaway agents.
1// Example: max $10,000 per transaction2NotionalConfig { max_per_tx: 10_000.0, max_per_second: None, max_per_minute: None }
Token-bucket rate limiter that restricts signatures per second. Prevents agents from overwhelming exchanges or burning through gas.
1// Example: max 100 signatures per second with 5s cooldown2RateConfig { max_signatures_per_second: 100, cooldown_seconds: 5 }
Restricts which smart contract addresses the agent can interact with. Enforced at the signing layer — the agent cannot sign a transaction to a non-whitelisted address.
Limits which blockchain networks the agent can operate on. Prevents cross-chain mistakes (e.g., signing a mainnet transaction when only testnet is approved).
Schedule-based restrictions. Supported presets:
us_market — only allows signing during US market hourscrypto_24_7 — always available (default for crypto agents)Custom windows can be defined for specific operational schedules.
The most advanced rule type. Loads an ONNX model inside the enclave to score each transaction request for risk. High-risk transactions (anomalous size, unusual counterparty, off-hours activity) are rejected before signing.
1Transaction → ONNX Model → Risk Score → Accept/Reject
The model runs inside the enclave, so the risk scoring logic is part of the attested code base — verifiable via PCR0.
All rule types are implemented as variants of a Rust enum with #[inline] evaluation methods. This gives the compiler full visibility for optimization:
1enum PolicyRule {2 Notional(NotionalConfig),3 Rate(RateConfig),4 Contract(ContractsConfig),5 Chain(ChainsConfig),6 Schedule(ScheduleConfig),7 AiRisk(AiRiskConfig),8}
The primary evaluation path uses enum-based static dispatch — the compiler generates a jump table for the match statement, keeping evaluation in the single-digit microsecond range.
Rules are loaded from a YAML configuration at enclave boot:
1version: 12name: "agent-policy"3rules:4 notional:5 max_per_tx: 10000.06 rate:7 max_signatures_per_second: 1008 cooldown_seconds: 59 schedule:10 preset: "crypto_24_7"
Changing rules requires rebuilding the enclave image, which changes the PCR0 hash — making policy changes auditable and verifiable.
The policy engine is transparent to the agent. The agent sends a sign request via vsock; the enclave evaluates all rules before producing a signature. If any rule rejects, the request is denied with a structured error indicating which rule failed.
1Agent → SignRequest(payload) → [Policy Engine] → Signature | PolicyDenied(rule, reason)
This means agents don't need to implement their own risk checks — the hardware enforces them regardless of the agent's code quality or intentions.