Security invariants
Sovereign is designed around a small set of hard security invariants. These are not configuration options — they are architectural constraints built into every layer.
No direct agent-to-signer path
There is no path from an agent SDK call to a signing operation. The SDK client exposes only proposal and query methods. The evaluation path runs through the constitutional runtime, not around it. Execution adapters act only on valid DecisionPackets.
This is not enforced by rate-limiting or policy flags. It is enforced by the absence of a signing surface in the SDK interface.
Typed intents only
Agents cannot submit free-form spending requests. Every economic action begins as a typed EconomicIntent with a known schema: wallet, agent, action kind, merchant, route, task, and idempotency key.
The runtime rejects any intent that does not match the expected schema for its action kind. Unknown or malformed intents are denied before reaching the evaluation stage.
Decision packets
The runtime issues DecisionPackets for approved actions. Each packet is:
- Scoped to the specific action that was approved — not a generic spend authority
- Signed by the runtime with a key not accessible to agents
- Short-lived with an expiry that cannot be extended by the agent
- Nonce-protected against replay attacks
- Intent-bound so a packet cannot be used for a different action
Execution adapters verify all five properties before acting. An expired, replayed, or mismatched packet is rejected and the denial is written to the audit log.
Budget reservations
When the runtime approves an intent, it reserves the budget amount before issuing the DecisionPacket. Reservations prevent concurrent intents from overrunning the wallet budget.
Reservations are committed on execution, released on denial, and reversed on adapter failure. The budget state machine ensures the wallet balance never goes below zero through concurrent approvals.
Merchant route fingerprinting
Each merchant route carries a fingerprint of its expected payment recipient. The runtime verifies the fingerprint on every intent. If the fingerprint has changed — indicating potential route compromise or payee drift — the runtime denies the intent and quarantines the route.
Quarantined routes require explicit administrative clearance. The quarantine event is written to the audit log with the original and observed fingerprints.
Memory firewall
Agents interact with the framework through the SDK. The SDK does not provide access to other agents' artifacts, wallet state, or decision history. Each agent's view is scoped to its own actions and to explicitly shared provenance records.
Live trading denied by default
The trading wallet constitution denies live execution unless explicit escalation is configured. Escalation requires an external approval step. The denial path is tested and audited — it is not a default that can be overridden by an agent parameter.
Paper trading requires a passing deterministic risk check. Paper orders are rejected if the risk check has not been completed or did not pass.
Audit hash chain
Audit events are append-only and form a hash chain. Each event references the hash of the previous event. The chain makes tampering detectable — any modification to a historical event invalidates the chain from that point forward.
Persistence and replay protection
Idempotency keys prevent the same intent from being processed twice. The runtime rejects a second submission of an intent with a key that already has a completed outcome.
In Postgres mode, the schema includes row-level versioning for decision packets and budget reservations. Concurrent modification is rejected rather than silently merged.