Autonomous agents are entering the institutions you already serve. PanGuard Sovereign is the control-and-proof layer they will need — and it reaches the customer through you. We supply the technology and the open standard; you hold the government relationship and the contract vehicle, deliver locally, and keep the account. What follows is the same architecture a national buyer sees, read from the partner's side.
Platform sovereignty asks an institution to trust a foreign vendor. PanGuard Sovereign is control the institution can verify — which is what sovereignty means.
Agentic systems are entering critical infrastructure and decision flows worldwide — calling tools, moving data, and chaining decisions on their own. For any sovereign institution, three gaps open that choosing a model, or a cloud, cannot close.
Prompt injection, tool poisoning, and over-autonomy can turn or over-reach an agent — it exfiltrates, escalates, or destroys in milliseconds, with no human in the loop. A safer model does not govern what the agent is permitted to do.
Policy exists on paper, but nothing enforces it at the point each agent acts — and supply-chain and advanced-model risks enter the decision unseen. Governing on any external hyperscaler puts the keys, the policy, and the audit trail beyond your reach in a crisis.
High-risk systems must produce demonstrable proof of what agents did and were allowed to do — for a regulator, an allied state, or an EU AI Act / NIST AI RMF obligation. “Trust us” is not a control.
Every tool call an agent makes passes a single decision point — detection against the open Agent Threat Rules standard, then authorization against your own signed national policy — and produces evidence anyone can verify offline. Deny-by-default: the absence of a decision is a denial.
On-premise or air-gapped, on infrastructure the institution owns. No outbound dependency, no phone-home, no foreign cloud in the trust path. The signing keys never leave your control.
Every decision is public-key signed; an auditor verifies it offline holding only a public key — without trusting the operator, the log, or us. Not “trust us”: prove it.
Built on the open Agent Threat Rules standard — vendor-neutral, not tied to any single foreign hyperscaler — with rules contributed to and merged upstream by maintainers. Your evidence outlives any one supplier.
PanGuard Sovereign is built on Agent Threat Rules (748 rules) — the open detection standard whose rules have been contributed to and merged upstream into projects maintained by leading security vendors and standards bodies — maintainer-accepted contributions, not vendor endorsements. Every entry below is independently verifiable.
Data, compute, model, and governance — the four dimensions nations use to define AI sovereignty. The architecture provides an enforced, auditable control for each, positioned in front of any agent, model, or tool platform already in operation.
Sensitive data is classified and its handling enforced as it flows — decrypted only where policy and hardware attestation permit.
Executes on hardware the institution controls — fully offline, no phone-home — releasing keys only to attested endpoints.
Model-agnostic by design. Governs any agent or LLM; an optional on-premise adjudicator may escalate for review, never authorize.
Every agent action is decided by the institution's own signed policy and written to a ledger any third party can verify.
Sovereignty means the institution need never take the supplier's word. Every security-critical action is cryptographically signed, and any party holding only a public key can verify it, offline.
Policies, approvals, break-glass grants, key releases, and every gate decision are Ed25519-signed at the point of action.
An auditor holding only the public key and an inclusion proof confirms a decision occurred — without the log, without the operator.
A missing identity, an unverifiable policy, or a broken audit path denies the action. Absence never resolves to allow.
Built on the open Agent Threat Rules standard. No black box and no proprietary data model to adopt.
In practice this is the evidence a national-security audit, a budget or procurement review, an EU AI Act Art. 12 / 26 high-risk logging obligation, and a NIST AI RMF audit trail require — produced continuously at the point of each decision, not reconstructed after an incident.
Showing a general, cross-framework mapping. Select your jurisdiction to see its deployment profile and the specific frameworks this maps to. Design-intent mapping — not a certification or accreditation.
| Control capability | Framework reference |
|---|---|
| Signed, tamper-evident decision ledger | EU AI Act Art. 12 (logging) · NIST 800-53 AU |
| Policy-as-code + least-privilege identity | NIST 800-53 AC · ISO/IEC 42001 |
| Signed, versioned policy distribution | NIST 800-53 CM (anti-rollback) |
| Classification, egress & jurisdiction control | NIST 800-53 SC · CUI handling |
| Human approval, break-glass, kill-switch | NIST 800-53 IR · human oversight (AI Act) |
| Air-gap signed delivery + supply-chain trust | SLSA-style provenance · supply-chain (SR) |
A country-specific compliance pack can be produced for any jurisdiction on request.
A working prototype under continuous independent adversarial review (approximately 1,700 automated tests; 30 review passes to date). Maturity is stated per capability against a two-state scale, defined in the legend below.
| # | Capability | Function | Maturity |
|---|---|---|---|
| 01 | Identity & least-privilege | Per-agent verified principal; delegation only attenuates, never widens | Implemented |
| 02 | Policy-as-code | Signed, versioned, deny-by-default; classification / jurisdiction / obligations | Implemented |
| 03 | Signed decision ledger | Ed25519 with Merkle transparency; third-party verifiable | Implemented |
| 04 | Data taint & egress control | Classification rides data; secret-egress and jurisdiction gates | Implemented |
| 05 | Human approval & break-glass | Signed single-use approvals; dual-control emergency override | Implemented |
| 06 | Supply-chain & A2A auth | Signed tool-trust catalogue; authenticated inter-agent messages | Implemented |
| 07 | Kill-switch | Enforced containment — severs the session; every subsequent call denied | Implemented |
| 08 | Policy-gated key release | Sensitive documents decrypt only at an authorized, attested endpoint | Implemented |
| 09 | Air-gap bundle | Signed manifest; the receiver verifies provenance before installing | Implemented |
| 10 | Operator console | Loopback, token-authenticated control surface with web interface | Implemented |
| 11 | Agent-facing HTTP fleet | Multi-session Streamable HTTP transport; per-session isolation and resource bounds | Implemented |
| 12 | Confidential-compute attestation | Measurement allowlist with key-binding anti-relay verification | Integration seam |
| 13 | On-premise adjudicator | Local model advises escalation only (tighten-only) | Integration seam |
| 14 | HSM / PKCS#11 signing | Hardware-held keys for jurisdictions that mandate a validated module | Integration seam |
Every sovereign-AI programme in your market is buying two things: sovereign compute and sovereign models. Almost none has the third — enforceable control over what autonomous agents do with sovereign data, and cryptographic proof of every decision. That layer has to be delivered locally, and that is your ground, not a foreign vendor's.
Autonomous agents are entering the ministries, operators, and critical-infrastructure customers you already serve. The control-and-proof layer is a requirement they will have to meet — under the EU AI Act, national AI laws, and their own regulators.
On the institution's own infrastructure, in its language, under its contract vehicle, integrated with the detection assets its SOC already runs. A foreign vendor cannot be in that trust path. You can.
PanGuard provides the runtime and the open Agent Threat Rules standard. You own the relationship, the contract, and the deployment. We do not compete for your account.
PanGuard is the technology supplier, not the prime. An in-country partner holds the local relationship and the contract vehicle; the institution keeps sovereign control. Each party owns a distinct part, so accountability and language stay in-country — a familiar supplier-to-integrator arrangement, not a new one to invent.
The delivery mechanism is built for an air-gapped environment and leaves cryptographic evidence at each step, so an auditor can later confirm exactly what was installed and that a human authorized it.
A signed bundle: a manifest over every file, signed by the delivery key.
Moved across the air gap on approved media. Nothing phones home; the runtime needs no outbound connectivity.
Offline, with only the published public key. The receiver confirms the signature and that every file matches the manifest before anything is installed; a mismatch fails closed.
A human signs acceptance (検収 / 驗収). The record recomputes the sign-off from the actual delivery steps, binds to the bundle's cryptographic identity, and is itself verifiable with only a public key.
Configuration and orchestration values are derived from your country pack; an unsafe network exposure is refused at deploy time, not left to a checklist.
A loopback operator console: human approvals, dual-control break-glass, and the kill-switch — every action written to the signed, tamper-evident decision ledger.
We work with a small number of established integrators per jurisdiction. The fit is usually clear on the first call.
If you deliver security or digital systems to government or critical infrastructure in your country, we should talk. Asynchronous, under NDA where needed — no obligation to evaluate.
If you are the buyer rather than the delivery partner, the same architecture reads from the institution's side — evaluation kit, staged path, and honest boundaries.
Sovereign compute and models answer whose hardware and whose weights. Enterprise agent-security platforms secure corporate agents inside a vendor's cloud. Sovereign agent platforms build and run agents on-premises. Each answers a real question — and each leaves the same one open: governing what an autonomous agent may do with sovereign data, and proving it to an auditor afterwards.
| Category | What it answers | What it does not |
|---|---|---|
| Sovereign compute & models | Whose hardware and whose weights run the AI | Does not govern what an agent may do with sovereign data, or prove it afterwards |
| Enterprise agent security platforms | Policy and posture for corporate agents, operated as vendor SaaS | Not air-gapped, not per-nation, and verification requires trusting the vendor |
| Sovereign agent platforms | Building and running agents on-premises | The platform is the party being audited — it cannot also be the evidence |
| PanGuard Sovereign | Enforces national policy at every agent action and emits evidence any auditor verifies offline with a public key — on an open, vendor-neutral standard | Not a model, not a cloud, not an agent-building platform |
Occupying a distinct position is not the same as leading a mature market. This is an early, verifiable implementation of that third pillar, at design-partner stage — offered for evaluation, not as a finished category.
PanGuard Sovereign is a reference architecture at design-partner stage, built on the open Agent Threat Rules standard. This brief describes a working prototype under active development — not a generally-available, certified, or accredited product. Framework references indicate design intent and traceability, not certification. Maturity and capability statements are current as of Revision 0.5 and are subject to independent verification.