Frequently Asked Questions

Authority makes an explicit governance decision — ALLOW, DENY, or ESCALATE — before any autonomous action executes. It evaluates the action against current policy and validated delegation, then produces a tamper-evident evidence record. The decision happens synchronously, in the critical path, before consequence occurs.

Authority renders governance decisions and produces the decision ledger. Observatory reads the decision ledger and derives governed traces, root-cause narratives, evidence bundles, and advisory signals. Observatory runs out-of-band and does not affect governance decisions or action latency. Authority is available independently; Observatory requires the Authority decision ledger.

Authority evaluates synchronously in the critical path — the action cannot proceed until a governance decision is rendered. The calling system proposes an action, Authority evaluates it against policy and delegation, and returns ALLOW, DENY, or ESCALATE before execution occurs. This is not an asynchronous audit or a background check — no action executes without a decision. Latency is measured per decision and reported as p50, p95, and p99 percentiles. We measure and report, not promise. The governance decision adds measurable latency. The alternative is executing without governance.

Authority operates at the action boundary. Bypassing governance requires bypassing the boundary itself — the same boundary through which actions reach downstream systems. Gaps in the evidence trail are detectable failures — not silent omissions.

No. Guardrails are probabilistic filters that constrain what a model can generate — they operate at the reasoning layer. Authority governs what happens when a model's output becomes a consequential action in a downstream system. Guardrails filter content. Authority governs execution. They address different problems at different boundaries.

No. IAM answers "can this identity access this resource?" Authority answers "was this action authorised under this policy, under which delegation, at this moment?" IAM controls resource access. Authority governs delegated authority for actions. They are complementary — you need both.

Policy engines evaluate policy decisions given inputs — often identity, resource, and attributes. Authority evaluates whether a consequential action is authorised under the governing policy and delegation model at the moment of execution. The decision occurs at the action boundary and produces a verifiable evidence record. Policy engines answer policy questions. Authority governs autonomous execution.

Logs record what happened after execution. Authority records the governance decision before execution. Logs describe events. Governance evidence proves authorisation — which policy applied, which delegation was in effect, and whether the action was permitted. Investigation is not governance.

Authority is governance infrastructure for autonomous systems. Traditional security controls focus on protecting systems — identity, network, and data access. Authority governs autonomous execution itself. When software systems begin acting on their own behalf, the critical control surface shifts from access to action. Authority operates at that execution boundary, ensuring that consequential actions are authorised under policy and delegation before they occur.

Autonomous systems change the location of risk. Traditional software produces outputs that humans review before acting. Autonomous systems produce actions directly — API calls, database writes, financial transactions, and other consequential operations. When software can act without human approval, governance cannot remain a policy document or an after-the-fact investigation. It must operate where consequences occur: at the execution boundary. Authority evaluates the action before it executes, ensuring that the system acts only under valid policy and delegation.

Authority sits between intent and execution. Agent frameworks, models, and orchestration systems generate intent — a proposed action. Downstream systems execute that action through APIs, databases, and external services. Authority inserts a deterministic governance decision between those two steps. It evaluates whether the action is authorised under policy and delegation before execution occurs, producing a verifiable evidence record that the action was authorised before it occurred.

The evaluation has two phases. Scoping identifies one action class, one enforcement point, and the delegation and policy model. Validation exercises ALLOW, DENY, and ESCALATE decisions in a controlled harness, verifies fail-closed behaviour, and confirms the evidence record surfaces who authorised what, when, and why. If the mechanism holds, we scope production deployment. If it does not, we stop.

Scoping is designed to take two to four weeks. Validation depends on the complexity of the action class and integration surface. The entire evaluation is designed to produce a clear decision — evidence that the mechanism works, or evidence that it does not — not an indefinite engagement.

Annual subscription. No per-decision charges, no per-seat counts, no micro-metering. Pricing is shaped by five dimensions: governed environments and actors, authority surface (action classes and downstream systems), enforcement planes, evidence requirements, and operating model. Governance infrastructure should not introduce usage anxiety. Full Commercial Model.

No. Authority is governance infrastructure deployed at the enforcement boundary. It requires scoping, policy definition, and delegation mapping specific to your environment. The design partner evaluation is the entry point — a structured process that validates whether the mechanism meets your governance requirements before any commercial commitment.

Authority operates within your environment — as an SDK wrapper, tool execution boundary, or local enforcement service. The decision path does not leave your trust boundary. Policy evaluation, delegation verification, and evidence generation all happen locally. Integration Overview.

No. Authority integrates at the action boundary — the point where autonomous intent becomes a consequential action in a downstream system. Agents continue to generate intent normally. Authority evaluates the resulting action before execution and returns a governance decision (ALLOW, DENY, or ESCALATE). Integration typically occurs through an SDK call, gateway enforcement point, or sidecar service, depending on where the action boundary exists in your architecture.

Authority is designed to fail closed. If the governance decision cannot be completed — due to service unavailability, timeout, or integrity failure — the action is denied. Autonomous execution does not proceed without a governance decision. This ensures that loss of governance infrastructure cannot silently permit unauthorised actions.

Authority is cross-runtime by default. It is not coupled to any specific agent framework, model provider, or orchestration system. It integrates at the action boundary — the point where autonomous intent becomes consequential action in a downstream system — regardless of how that intent was generated.

Yes. Authority deploys within your infrastructure, wherever actions are executed. It does not depend on a specific cloud provider, region, or managed service. The enforcement boundary is defined by where actions occur, not where infrastructure is hosted.

Authority runs in your environment. Governance metadata and evidence records remain within your trust boundary. Ambit does not access your environment unless explicitly granted for support. Observatory (where applicable) ingests governance receipts and metadata — not application payloads. What is stored, hashed, redacted, and retained is a first-class governance decision, not a default. Full Security Architecture.

Authority produces timestamped decision records tied to the policy version and delegation chain in effect at decision time. This evidence model is designed for regulatory inquiry and audit — it provides the technical records your compliance programme depends on. Because Authority deploys within your environment, enforcement and evidence remain within your audit boundary.

Yes. Evidence records are deterministic — identical inputs produce identical decisions and byte-identical receipts. Records are hash-chained (each record commits to its predecessor), creating an append-only, tamper-evident evidence stream that can be independently verified and replayed without access to the originating system.

Your organisation does. Policy, delegation models, and enforcement configuration are defined and versioned within your environment. Authority evaluates actions against the policy version active at decision time and records that version in the evidence record. Ambit does not modify governance policy without explicit change management in your environment.

No. Authority records decisions in a hash-chained evidence ledger where each record commits to the previous one. Any modification breaks the chain and is immediately detectable. Because decisions are deterministic and replayable, independent verification can confirm that the recorded governance decision matches the inputs evaluated at execution time.

Authority records the policy version, delegation chain, and evaluation result active at the moment an action is authorised. Each decision produces a deterministic evidence record tied to those inputs and committed to the append-only decision ledger. This makes it possible to determine who authorised the action, under which policy, and with what scope at the time it occurred — even long after the event. Because decisions are deterministic and replayable, identical inputs reproduce the same decision and byte-identical receipt, allowing independent verification during investigation, audit, or regulatory review.

Report vulnerabilities to security@ambit-systems.com. We acknowledge reports within two business days and coordinate a remediation timeline. Security advisories are published for confirmed vulnerabilities. Full Disclosure Policy.