Governed execution for autonomous AI.

Modern AI agents reason, plan, and act autonomously. Granting them direct access to production infrastructure — through static credentials, broad scopes, and after-the-fact monitoring — reproduces the failure modes of legacy access control and amplifies them at machine speed.

DecisionGuard introduces a deterministic execution model in which no agent action is possible without a cryptographic decision artifact issued by a governing authority, validated by a local enforcement point, and bound in scope, parameters, and time.

Foundational commitments

• No standing infrastructure access for agents. Every operation routes through a governed execution boundary.
• Cryptographic gating, not advisory policy. Without a valid certificate, the tool does not run.
• Decisions precede execution. Every action is bound to an authorization issued before it occurs.
• Progressive adoption. Evidence-only mode delivers value on day one without forcing inline enforcement.

Enterprise security evolved to manage human operators. Humans are slow, intentional, supervised, and held accountable through social and legal structures. Autonomous agents are none of these things. They reason unpredictably, operate continuously, and diverge from intent under edge cases their authors never anticipated.

Assumptions traditional models depend on

• Static credentials grant stable, long-lived access that can be safely scoped at provisioning time.
• Over-permissioning is tolerated to avoid blocking legitimate workflows.
• Logging and monitoring enable detection and remediation after incidents.
• Advisory enforcement — policies are observed or recommended, but not cryptographically required for execution.

Traditional access control cannot answer the only question that matters at the moment of action: should this specific agent perform this specific action, with these specific arguments, against this specific resource, right now?

The consequences

• Over-privileged agents granted access for what might be needed, not what is explicitly approved.
• Unpredictable execution that diverges from operational intent without triggering any structural control.
• Weak traceability connecting reasoning, decisions, and resulting actions.
• Compounding regulatory exposure under EU AI Act, NIS2, DORA, and sector-specific oversight regimes.

A DGAC is a cryptographically signed, single-use execution certificate that binds a decision in scope, parameters, target, and time. It replaces standing credentials with single-use execution rights. It replaces “what an agent can do” with “what an agent has been explicitly authorized to do, here, now, exactly this way.”

Anatomy of a certificate

• Intent — a human-readable statement of what the agent is attempting. The semantic anchor for audit.
• Tool — the exact capability being invoked. Identifier-bound, no aliasing.
• Arguments — frozen at issuance. No substitution is permitted between authorization and execution.
• Target — the resource identity. A certificate issued for one bubble cannot be replayed against another.
• Constraints — predicates that must hold during execution: egress controls, byte limits, DLP profiles, time windows.
• Validity window — short-lived TTL measured in minutes or seconds. Expiry is enforced; replay is impossible.
• Consumption state — a DGAC can be active, held, revoked, or consumed. Execution requires live valid state.
• Signature — Ed25519 signature over the canonical certificate body, verified at the enforcement point.

A DGAC is not a session, a role, or a bearer permission. It is a decision artifact. It proves that a specific action was explicitly authorized at a specific moment, by a specific authority, under specific constraints, and bound to a specific reasoning trace.

DecisionGuard governance operates across three distinct phases. Each phase has a single responsibility, runs in a different trust domain, and produces an output the next phase depends on. Together they form the AAA Model.

Phase 01 — Assurance

Captures the agent’s proposed action, the surrounding reasoning trace, and the operating context. Risk is assessed against historical baselines, behavioral signatures, and the structural sensitivity of the requested operation. The output is verifiable evidence — independent of any later decision.

Phase 02 — Authority

Evaluates the request against policy. Applies fine-grained constraints — argument bounds, target restrictions, time windows, and approval requirements. Issues a DGAC only when every condition is met. Authority is the only phase that can produce certificates; it can also produce DENY, REQUIRE_APPROVAL, or ESCALATE verdicts.

Phase 03 — Autonomy

The local enforcement point — the ToolHub — validates the certificate cryptographically, checks its state live, holds its constraints during execution, and runs the tool. A mandatory enforcement wrapper ensures that no tool can execute without first presenting a valid, unexpired, unmodified DGAC. The earlier vulnerability — an agent receiving a verdict and ignoring it — is structurally closed.

Each ToolHub instance creates a governed execution bubble inside the customer environment — an isolated, cryptographically enforced zone that owns local infrastructure and refuses to execute anything without a valid DGAC. Agents remain outside the bubble and never receive direct infrastructure access.

Properties of every bubble

• Local infrastructure connectivity — direct access to databases, APIs, and cloud control planes inside the bubble; latency stays low because the gate is co-located with the resources it protects.
• Isolated execution boundary — no cross-bubble interference; a compromise in one bubble cannot pivot through DecisionGuard to another.
• Zero direct agent access — agents cannot reach infrastructure under any path; the only ingress is the DGAC gate.
• Mandatory enforcement wrapper — every tool invocation passes through a wrapper that refuses to run without a valid certificate. Verdicts cannot be silently ignored by the agent runtime.

Agents increasingly reach tools through the Model Context Protocol (MCP) — a standardized handshake for tool discovery and invocation used by Claude Desktop, Claude Code, and a growing set of custom agent frameworks. DecisionGuard implements a governed MCP surface so any MCP-compliant client can call tools through the same DGAC-gated boundary, without a bespoke SDK integration per agent.

The gateway negotiates protocol version, exposes a catalog-driven tool list, and transparently proxies both first-party ToolHub tools and upstream third-party MCP servers — while every tool call is still evaluated against the AAA model before it is allowed to execute. From the agent's point of view, it is simply talking MCP. From the architecture's point of view, nothing invoked over that surface bypasses the DGAC gate.

What the gateway provides

• Standards-based handshake — protocol version negotiation, streamable HTTP and SSE transports, session-scoped identity.
• Catalog-driven discovery — tools are resolved from the governed catalog, not hardcoded per client.
• Per-tool replay policy — ONE_TIME certificates for state-changing actions; MULTI_USE for polling and status tools within a job.
• Upstream MCP proxying — third-party MCP servers are governed the same way as native ToolHub tools.

A decision is only as trustworthy as the identity behind it. Beyond authorizing what an agent may do, DecisionGuard binds every certificate to who — or what — is accountable for the decision: a verified human, a human-delegated mandate, or a service identity operating with no human in the loop.

Identity is resolved from verified sources — SSO/IdP sync (Okta, Entra, Google), on-behalf-of headers validated server-side, and device-authorization binding for headless CLIs and daemons — never from caller-supplied claims alone. A caller cannot assert its own accountability; the platform resolves it.

Authority modes pinned on every certificate

• human_direct — a verified human acting in an interactive session, resolved through SSO/IdP.
• human_delegated — a human-issued mandate authorizing an autonomous agent to act on their behalf, within scope and time bounds.
• service_account — a machine identity with no human in the loop, held to the same non-repudiation standard.
• legacy_unknown — pre-DGAC callers that have not yet completed identity binding, flagged for migration rather than silently trusted.

Because authority mode is resolved and signed at issuance — not inferred after the fact — every audit event and every evidence bundle can answer who approved this, and under what authority without reconstructing intent from logs.

The full request lifecycle is the operational unit of DecisionGuard. Every governed action follows the same path; every step is logged, signed, and replayable.

If verification fails at step 6 — expired TTL, modified arguments, wrong target, revoked state, or invalid signature — the wrapper short-circuits and the tool never runs. The denial itself becomes a signed audit event linked to the original request.

Policy is centralized; execution is distributed. A single DecisionGuard authority issues certificates; execution happens at any number of regional ToolHubs, each owning a slice of infrastructure with its own residency, latency, and compliance profile.

What this topology enables

• Geographic isolation — separate bubbles per region for GDPR, NIS2, and data residency requirements that prohibit cross-border data movement.
• Infrastructure isolation — each bubble owns its local services; failures and breaches do not propagate.
• Unified governance — a single authority controls every bubble through identical policy semantics.
• Horizontal scaling — new bubbles join the topology by registering with the authority; the policy engine never changes shape.

Not every environment can host a full ToolHub. Edge nodes extend governed execution to developer laptops, on-prem servers, and customer VPCs with no inbound connectivity — a lightweight agent that maintains an outbound-only relay connection back to the Authority, so no inbound firewall rule is ever required.

Each edge node carries a bound identity, attested at registration, and executes only tool calls accompanied by a valid DGAC relayed from the central policy engine. If the relay connection drops, the node fails closed rather than executing ungoverned.

What every edge node guarantees

• Outbound-only relay — no inbound ports; the node initiates and holds the connection to the relay.
• Bound node identity — attested at registration and re-verified so a relay key cannot be replayed against a different node.
• Fail-closed on disconnect — a node that loses its relay connection cannot execute; it queues or refuses, never falls back to ungoverned local execution.

DecisionGuard does not require an enterprise to bet its operations on day one. The same architecture supports three enforcement postures, and tenants progress through them as confidence accumulates.

The properties below are not features bolted onto a runtime — they are direct consequences of the architecture. They hold whether DecisionGuard is deployed for a single agent or for an enterprise fleet. Governance events also compound into a continuous compliance evidence layer: audits, corrective actions, and management reviews are fed by the same signed decision trail, not assembled as a point-in-time snapshot.

Most of the market answers one question: is this prompt or output safe? Hyperscaler AI platforms answer it with content filters and identity/access controls scoped to their own cloud. Specialist guardrail vendors answer it with prompt- and output-layer scanning that works across models but stops at detection. DecisionGuard answers a different question: was this exact action explicitly authorized, right now, in this exact way — and can that authorization be cryptographically proven after the fact? That is an execution-layer primitive, not a bigger filter, and it is why the comparison below spans a different axis than typical feature-for-feature vendor tables.

Comparison reflects each vendor's public documentation as of August 2026. Hyperscaler platforms (Anthropic, Microsoft, AWS, Google) continue to expand identity, RBAC, and content-safety controls within their own clouds — that is real progress, but it governs content and access, scoped to one vendor's models and infrastructure. Specialist guardrail platforms (Lakera, CalypsoAI, Credo AI and similar) are the closest architectural cousins: vendor-agnostic and cross-model by design, but operating as a prompt/output inspection and risk-inventory layer rather than a cryptographic, pre-execution authorization primitive bound to the tool call itself. DecisionGuard's differentiation is structural, not incremental: authorization happens once, deterministically, before execution — independent of which model, cloud, or vendor initiated the request.

Governance is only half the story, and framing DecisionGuard purely as a control layer undersells what it enables. Every enterprise agent program eventually hits the same wall: agents need dozens of tools, and each new integration has historically meant a bespoke credential, a one-off security review, and weeks of engineering before an agent could touch it. The same platform that authorizes every action in this document also ships a governed Connector and Service Directory — pre-built MCP and REST/API connectors that a team turns on in minutes, not sprints, without giving up any of the authorization guarantees described in the sections above.

15.1 — The connector economy

Connectors in the Directory (Gmail, Drive, GitHub, Slack, Jira, and dozens more) are interchangeable by design. Swap Gmail for Outlook, Slack for Teams, or a demo CRM for the production one, and nothing about how an agent is authorized changes — the DGAC gate, the AAA phases, and the audit trail sit underneath every connector identically. Teams are never locked into today's stack; they are free to add, replace, or retire tools as needs change, because governance is bound to the action, not to the vendor that happens to ship it.

15.2 — One vault, zero sprawl

That same catalog is where the credential-sprawl problem gets solved, not relocated. Every connection is stored once, per tenant or per user, inside a single governed vault — never copied into agent configs, environment files, CI secrets, or a scattered secrets manager per project. Personal and company-scoped connections stay distinct, and every tool resolves the right credential automatically at dispatch time — at the moment a call is actually authorized to run, not before, and never handed to the agent directly.

15.3 — Governed at every hop

None of that speed comes at the expense of the model this document has built up to this point. A connector call dispatched through the Directory passes through the identical authorization and audit chain as a terminal command or a browser action — the same DGAC gate, the same decision graph, the same replayable evidence. Teams get the speed of a plug-and-play integration marketplace and the assurance of a single governed execution path, because in this architecture the two were never a tradeoff — they are the same primitive, applied twice.