Build around an explicit authority boundary.

Architecture guidance for identifying autonomous principals, defining grants, evaluating consequential actions and preserving evidence.

Concept models help plan an integration. They are not a fabricated public API or install guide.

Selected paths

Work from the decision model.

Developers / Concept Model

Model principals and delegated grants.

Represent the facts needed to explain where autonomous authority originated and how it narrowed.

Explore this path Developers / Concept Model

Runtime decisions before execution.

Treat ALLOW, DENY, ESCALATE and DEGRADE as distinct action-time outcomes with different execution consequences.

Explore this path Developers / Architecture Guide

Patterns for placing the authority check.

Identify where agent, tool, API and machine workflows cross from intent into an external effect.

Explore this path

All Developers

More to explore

Getting started with an authority design.A practical sequence for scoping an integration before choosing interfaces or writing adapters.Evaluate a policy envelope.Turn a valid authority grant into an action-specific decision using target, purpose, context and operating limits.Evidence that links decision to outcome.A conceptual event model for reconstructing an autonomous action without inventing a production schema.Implement an agent policy enforcement pointA PEP must intercept every path that can create a protected effect.Implement a policy decision pointA PDP evaluates a trusted principal, grant, action, resource and current policy state into an explainable decision.Represent an authority grantAn authority grant should encode issuer, subject, action scope, resources, task, expiry and delegation constraints.Validate a delegation graphA child action is permitted only if every ancestor grant is valid and each edge narrows authority.Design a policy envelopeA policy envelope gives an action a bounded set of allowed effects and current constraints.Validate grant signaturesCryptographic integrity helps only when issuer trust and grant meaning are also verified.Propagate revocation eventsRevocation must invalidate descendant rights and cached decisions before another protected effect.Implement shared authority budgetsA common budget must be reserved atomically across parent and parallel children.Bind human approval to an actionApproval must apply to the exact normalized effect the reviewer saw.Prevent authorization replayAn allow or approval cannot be reused for a different effect or beyond its permitted count.Design idempotency keys for agent actionsThe same business operation needs one stable key across uncertain retries.Close authorization time-of-check to time-of-use windowsThe object and arguments evaluated must be the ones the executor actually changes.Generate authorization decision receiptsA receipt records evaluated permission, not execution or observed success.Generate execution receiptsThe executor should attest what request it accepted and what response or uncertainty it observed.Verify observed outcomesAn independent read of authoritative state distinguishes a tool response from a completed effect.Implement cross-runtime agent delegationA handoff across runtimes needs verifiable origin and narrower child rights.Handle agent fan-outParallel children should receive independent narrow grants but share aggregate constraints.Handle agent convergenceResults from multiple children must not combine into authority none of them possessed.Implement fail-closed agent decisionsMissing authority facts should not silently become ALLOW for consequential actions.Implement reduced agent operating modesA degraded mode explicitly permits a smaller set of effects when current authority cannot be checked.Authorize offline edge actionsEdge autonomy needs preissued, short-lived permission for a narrow action while disconnected.Authorize edge reconnectionA returning edge agent must reconcile stale grants and actions before resuming normal authority.Measure authorization latencyAction-time checks need latency metrics that reveal both performance and unsafe bypass.Cache authorization decisions safelyOnly a precisely bound and fresh decision can be reused.Version agent policiesA decision must be explainable against the exact policy bundle in force.Test agent policiesPolicy tests should exercise grants, denials, changed context and downstream bypass paths.Observe agent authorization decisionsDecision telemetry should reveal unexpected allows, denials and missing enforcement without leaking protected arguments.Design audit events for autonomous actionsAn audit record should connect authority origin to decision, attempt and observed outcome without logging secrets.Debug an authority chainA denial can be explained by walking the relevant grant edges and current constraints.Design denial reasonsDenial codes should be stable and useful without revealing unrelated entitlements.Place enforcement in an agent tool wrapperA tool wrapper can normalize and deny calls before invoking a downstream API, but it protects only calls that pass through it.Place enforcement in an API gatewayAn API gateway can block routed requests using authenticated caller and normalized operation context.Place enforcement in the executorThe system that commits an effect can compare the exact request with a current authority decision.Implement MCP tool authorizationAn MCP tools/call request needs action and argument authorization beyond transport access.Validate MCP token audienceAn MCP resource must reject access tokens not issued for that canonical server.Avoid MCP token passthroughAn MCP server must not forward a token issued for itself to a downstream API as if its audience covered that API.Log MCP execution evidenceMCP tool results need correlation to the actual downstream attempt and observed result.Implement agent task cancellationCancelling a task must stop queued consequential actions and withdraw dependent grants.Implement approval expiryA human approval should end at a fixed time and when its task or target changes.Implement agent policy simulationA proposed policy can be evaluated against historical decision inputs without granting live effects.Implement agent policy rolloutPolicy activation should be staged, observable and reversible without inconsistent executor decisions.Model consequential agent actionsAction classes should reflect real-world effects, not just tool names.Detect alternate execution pathsA policy boundary is incomplete if another route can reach the same protected effect.Implement tenant isolation for agentsTenant context must come from authenticated authority and survive every agent handoff.Implement emergency authority overrideBreak-glass permission should be narrow, time-limited, independently auditable and separately initiated.

A working perspective

Complete authority model

ProofGrid accepts identity, authentication, authorization, access-control and audit facts as inputs to its authority platform.

ProofGrid provides delegated authority for autonomous principals, continuous trust and runtime action control. These pages explain the public technical model and integration behavior without publishing private endpoints, schemas or implementation details.

Identity and access context
Authority grants and graphs
Policy and continuous-trust inputs
Runtime control and verification

Start with a protected action

Do not begin by copying credentials into an agent runtime. First identify which operation can create an external effect. Name the principal, map the origin of permission, define the policy envelope and decide where execution can be stopped. Then design the evidence needed to explain the result.

Developers / Discussion

Define the boundary before the effect.

Request a Conversation