# Aegis Runtime Authority | Control Governed AI Actions Canonical page: https://spqrtech.ai/aegis/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Operational AI governance Independent runtime authority # The agent can propose. *It cannot authorise itself.* Aegis independently verifies signed, scoped authority for governed actions. The integrated enforcement point applies the decision before a tool, API or workflow creates an effect. Allow, deny or escalate, with inspectable decision evidence. [See one action end to end](https://spqrtech.ai/aegis/#action-boundary)[Review one workflow](https://spqrtech.ai/contact/#authority) One workflow · agreed scope Inspectable decision evidence Fails closed by default ILLUSTRATION · fictional tenant/acme ILLUSTRATIVE EXAMPLE 01 **send\_email → customer**comms-v4 · region in-bounds · signed HEAD verified ALLOW · 31ms example 02 **export\_file → external**dlp-v2 · manager approval required ESCALATE · 28ms example 03 **call\_api → payments.refund**outside trust boundary · fail-closed DENY · 12ms example Illustrative action decision ✓ **Allowed**mapped · in bounds **31 ms**example timing, not a benchmark **Verified**signed authority head: 0x7f3a…a91f · bundle: sha256:4c9e…d21b · verified ✓ ClauseCOMMS-4.2 · approved customer contact Signeracme-kms/policy-authority-01 OutcomeAction executed · receipt written ILLUSTRATIVE UI · Fictional identifiers and sample timings, not live telemetry or a latency benchmark. Proofs, not promises. **SOC 2 Type II**Controls independently examined **ISO/IEC 27001**Certified information security management **ISO/IEC 42001**Certified AI management system Scripted demonstration ## Explore the control pattern *in action.* Scenario verdicts and audit records in this preview are simulated. This is not a live security test and does not produce production governance evidence. The preview is hosted at app.spqrtech.ai. Load it only when you are ready. Load the scripted preview[Open preview in a new tab](https://app.spqrtech.ai/preview/) Prefer a local explanation? [Follow one action end to end.](https://spqrtech.ai/aegis/#action-boundary) The operating principle ## Why was that action allowed? *Show me.* The claim is not that an AI answer is correct. It is that a governed effect passed through an authority decision and an enforcement point that people can inspect. ### Policy before effect Use approved, active authority rather than letting the actor invent permission. ### Decision outside the model Treat the model output as a proposal requiring independent authorisation. ### Evidence at the boundary Record the relevant control state, decision and resulting effect or block. The problem ## AI systems are becoming *action engines.* The system proposing an action should not be the only system deciding whether it is allowed. Context can inform. Logs can report. Neither can independently stop the action. Not restraint ### Prompts ask nicely. Prompt-only controls influence behaviour. Some other guardrails also enforce external permissions. Compare the actual action path and its enforcement. Not retrieval ### Context is not control. RAG gives the model governed reading material. It still holds the pen. Aegis holds the authority to act. Not after the fact ### Logs cannot prevent. Monitoring reports the breach. Runtime control decides before the API, workflow, or record is touched. A field note ## Better agents need *explicit authority.* Prompts are not permission. A new route is not a new mandate. These are questions to test alongside existing controls, not a claim that other teams have built none. [Explore Brake Pedal](https://spqrtech.ai/brake/) A scoped evaluation, not an automatic rollout ## One workflow. *A test that can say no.* Agree the objective, environment, required evidence, cost and delivery plan before integration. A four-week plan can be a scoping target; timing depends on access, approvals and complexity. 01 ### Scope Name the workflow, owner, allowed actions, prohibited effects and stop conditions. 02 ### Prepare Review policy material. Compile and sign the agreed governance bundle; independently verify it before activation. 03 ### Evaluate Keep existing safeguards. Test legitimate completion, false denials, unauthorised effects, bypasses and recovery in an isolated environment. 04 ### Decide Inspect the evidence and operating burden. Proceed, revise or stop before considering another workflow. The deliverable is a scoped findings and evidence pack. It is not regulator approval, a compliance certificate or a guaranteed enterprise rollout. [Read the evaluation protocol](https://spqrtech.ai/challenge/) Integration is an engineering decision ## Choose the enforcement seam *you control.* These are integration patterns, not a claim that every platform has a shipped native connector. Confirm support for the exact environment during scoping. 01 ### Tool-call integration Place a trusted enforcement point around a tool invocation. It submits the action for an Aegis decision and applies the result before calling the tool. 02 ### Action gateway Mediate supported tool or API traffic through a controlled gateway. Routing, credentials, operation mapping and bypass handling need to be configured. 03 ### Platform action hooks Use a platform’s available authorisation hook where it can genuinely hold execution. Validate the platform, adapter and version rather than assuming universal compatibility. PSEUDOCODE · EXPLAINS THE PATTERN, NOT A PRODUCTION SDK CONTRACT ``` proposal = agent.propose(action_context) decision = authority.evaluate(proposal, trusted_context) # A trusted enforcement point owns the tool credentials. enforcement.apply(decision, exact_action=proposal) # No verified permission: no governed effect. # On escalation: wait for a valid approval and re-evaluate. ``` The architecture ## Proposal. Decision. *Enforced effect.* ILLUSTRATIVE ARCHITECTURENot live telemetry 1. **01 · AGENT****Proposes an action**Operation, target and context 2. **02 · ENFORCEMENT POINT****Holds the action**Sends the request to Aegis 3. **03 · AEGIS / DECISION****Verifies active authority**Scope · policy · provenance · approvals 4. **04 · ENFORCEMENT POINT****Applies the verdict**Allow, deny or escalate before effect 5. **05 · TOOL & EVIDENCE****Permitted effect is recorded**Tie the effect or block to the decision An authorisation decision is not enforcement by itself. Direct credentials and alternative routes must not bypass the integrated control. ### Where the claim ends Aegis does not automatically remove direct credentials, close an unmediated route, fix an underlying tool vulnerability or guarantee that an approved policy is appropriate. Those assumptions must be reviewed and tested with the integration. Scoped authority ## A policy stack, *not one flat file.* Each layer narrows the operating envelope for the one beneath it. Internal policy can add stricter local rules; it cannot silently weaken the baseline floor. **Platform baseline**Regulation, standards, industry packsFLOOR **Organisation overlay**Company policies, controls, proceduresL2 **Department overlay**Local rules, approvals, exceptionsL3 **Agent / workflow scope**Allowed operations, trust region, runtime HEADL4 **Aegis runtime authority**Active signed composition of the full stackHEAD ✓ Before runtime ## Authority has to come *from somewhere.* Praxis assesses and remediates organisational policy against the assigned regulatory baseline. Aegis verifies and enforces the approved authority at runtime. **Aegis should enforce authority the organisation has actually established and approved. It should never need to invent it.** **Praxis**Establish and agree authority → **Aegis**Verify and enforce authority [Explore Praxis Policy Assurance](https://spqrtech.ai/praxis/) Compare the actual job ## Complement. Duplicate. *Fail.* All three are useful findings. A fair comparison keeps the customer’s existing controls in place. Distinct control jobs; existing products can cover more than one. | Control | Useful job | Question at the action boundary | | --- | --- | --- | | Policy and retrieval | Make rules available for reasoning and review. | Which approved, active authority actually applies? | | Sandbox and identity controls | Restrict reachable resources and establish identity. | Is this specific action authorised in its current context? | | Human approval | Put designated people in the decision path. | What exact action was approved, and is that approval still valid? | | Runtime policy enforcement | Independently authorise and mediate effects. | Does the existing implementation already meet the need? | | Monitoring and audit | Record and detect relevant activity. | Can records tie the actual effect to the authority decision? | What you can prove later ## Every governed action leaves a *verifiable chain.* The claim is not “the AI was right.” It is that the system followed a reviewed, signed, active policy state; and you can inspect the receipt for any single action. The receipt and control-state values below are illustrative. [Measured sandbox results and their limits are separate.](https://spqrtech.ai/evidence/) 01 ### Policy in Approved clause set, source-span mapped and digested. sha256:4c9e…d21b 02 ### Signed Deterministic bundle, hashed and signed with your key. sig:0x7f3a…a91f 03 ### Verified Runtime pointer checked live before any decision runs. head@a91f ✓ 04 ### Verdict Allow, escalate, or deny with the mapped operation. allow · 31ms example 05 ### Receipt What was touched, tied back to the signed state. rcpt:9b2c…f04e The proof artefact ### Not a dashboard claim. A receipt. Every governed action can be traced back to the exact authority active at the moment of execution. - Mapped operation and target - Applicable policy clause - Signing authority and active HEAD - Verdict, latency, and effect ILLUSTRATIVE RECEIPT · SAMPLE VALUES, NOT MEASURED EVIDENCE AEGIS / DECISION RECEIPT / RCPT-9B2C-F04ESIGNATURE VERIFIED ✓ Decision at 14:07:31.204 AEDT ### Action allowed. ✓ Operation**send\_email → customer** Decision time**31 ms** Policy clause**COMMS-4.2** Scope**org/acme/dept/sales** Signing authority**acme-kms/policy-01** Effect**executed · receipt written** head: 0x7f3a…a91f · bundle: sha256:4c9e…d21b · receipt: sha256:9b2c…f04e Built for the whole decision ## One control plane. *Four reasons to care.* Aegis gives every member of the buying committee an answer in the language of their responsibility. For Legal ### Which authority applied? Identify the approved policy, delegation and signing authority behind the action. Inspect the applicable rule without treating a signature as proof that the policy was legally correct. For Risk ### Where can the action escape? Map the governed operations, alternative routes and human approval requirements. Test missing authority, stale policy and recovery with the enforcement point in place. For Audit ### Can the decision be reconstructed? Tie the policy state, operation, approval and decision to the observed effect or block. Keep example receipts separate from measured evaluation evidence. For Technology ### What will the integration require? Confirm the supported tool-call, gateway or platform-hook pattern. Agree credential isolation, key custody, latency expectations, logging and operational ownership. [Share the one-page authority brief with your decision group.](https://spqrtech.ai/brief/) Trust and deployment ## Know what the control *depends on.* ### Signing and custody Agree who controls the signing authority, runtime activation and key rotation. Define the supported HSM/KMS or managed-key arrangement for the deployment. ### No authority, no governed effect The integrated enforcement path must fail closed when required authority cannot be established. Outage behaviour and recovery need testing, not just a diagram. ### Data and evidence handling Agree what action context, decision records and logs are processed, where they live and how long they are retained. Do not infer a zero-retention guarantee from the architecture. **SOC 2 Type II****ISO/IEC 27001****ISO/IEC 42001**[Request assurance scope and documentation](https://spqrtech.ai/trust/) Earn the next deployment ## Evidence first. *Expansion second.* A useful result on one workflow does not establish fitness for every agent, department or tool. Re-check policy, integration, operating ownership and acceptance criteria for each expansion. [Discuss one workflow](https://spqrtech.ai/contact/#authority) Who is accountable ## Built by people who have owned *enterprise control planes.* SPQR builds independent control infrastructure for agentic AI. We are a focused team out of Melbourne with backgrounds in policy compilation, distributed systems, and enterprise security engineering. We do not sell another AI assistant. We sell the layer that decides what your assistants are allowed to do; and the evidence to prove it held. - Enforcement over persuasion; the model asks, Aegis decides. - Prove it or it did not happen; every decision leaves a receipt. - Agree key custody, evidence retention and fail-closed behaviour for the deployment. ### Adam Mazzocchetti Co-founder · CEO AM Adam speaks with every early design partner directly. Bring one workflow and he will walk the chain with you, action by action. [Start a conversation](https://spqrtech.ai/contact/#authority) [LinkedIn](https://www.linkedin.com/in/adammazzocchetti/) ### Misha Notra Co-founder · COO MN Misha leads the technical architecture and engineering of Aegis, turning signed policy authority into reliable runtime infrastructure for agentic systems. [LinkedIn](https://www.linkedin.com/in/misha-notra-356b061ba/) One clear next step ## Put one workflow *on the table.* Map the current authority boundary. Compare it with Aegis. Decide whether there is a useful test to run, with no production access required for the first conversation. [Request a 20-minute authority review](https://spqrtech.ai/contact/#authority)[Inspect the test protocol](https://spqrtech.ai/challenge/) One workflow. Defined scope. A decision about fit.