This architecture is fully implemented in the AGF Authorization Runtime v0.3.0.
Reference Architecture
How agent governance works
The AGF architecture is a hybrid model: policy is authored centrally and evaluated in a distributed PDP cluster, while a separate trust evaluation service assesses lineage and risk independent of business logic. Every decision produces a signed, replayable artifact. No central bottleneck; no unauditable gaps.
§1 — Architecture Overview
Request evaluation flow
Source
Policy Repository
Git-backed · versioned
Requestor
Agent
Signed identity · session token
Risk Engine
Trust Evaluation Service
Lineage · anomaly · composite score
Evaluation
Distributed PDP Cluster
Policy evaluation · delegation validation · risk aggregation
Output
Decision Artifact
Signed · replayable · append-only log
The Policy Repository and Trust Evaluation Service operate independently of each other — policy evaluation and risk evaluation are deliberately separated so that neither can be gamed by compromising the other. The PDP combines both inputs before signing a decision.
§2 — Trust Zones
Three trust zones
Authority is tiered across three zones. Most decisions flow through the Domain Authority. The Local Authority handles hot-path caching; the Global Authority provides the cryptographic root that makes cross-organizational trust possible.
Local Authority
Agent itself
The agent evaluates permissions it already holds — cached grants from a prior domain authority check. Fast, but cannot issue new grants. Suitable for repeated low-risk actions within an already-authorized scope.
Used for
Routine tool calls within an active session, hot-path latency-sensitive checks.
Domain Authority
Enterprise trust service
The primary decision point for nearly all real-world agent actions. Evaluates the full policy set, validates delegation chains, checks revocation state, and issues signed decision artifacts. Most governance work happens here.
Used for
New action types, cross-system access, delegation validation, any action with non-trivial risk score.
Global Authority
Root trust anchor
Invoked rarely — for initial agent registration, cross-organization trust establishment, and root credential issuance. Acts as the cryptographic anchor for the entire trust chain. Results are cached aggressively; direct calls are infrequent by design.
Used for
Agent provisioning, cross-org delegation, root key rotation, global revocation events.
§3 — Risk Layers
Three risk layers
Risk is not a single number. Each layer captures a distinct dimension that the others cannot — they are combined into a composite score at evaluation time and compared against a per-action threshold defined in policy.
Inherent Risk
A baseline risk score attached to an action type by policy authors. It reflects the intrinsic danger of the operation regardless of context — deleting a database carries high inherent risk; reading a public record carries low inherent risk. Defined once in policy, applied universally.
Environmental Risk
A modifier calculated at evaluation time by the verifier based on execution context. The same action can carry different environmental risk depending on when it happens, from where, at what volume, and after what sequence of prior actions. Environmental risk captures the anomaly signal that static policy cannot.
Trust Risk
A risk component derived from the agent's delegation lineage. How many hops from the originating human? How recently were the credentials issued? Has any principal in the chain been flagged or had permissions modified? Trust risk is not about the action — it's about how much the trust chain behind the agent has degraded.
Composite risk formula
composite = w₁·inherent + w₂·environmental + w₃·trust
where w₁ + w₂ + w₃ = 1.0
weights configured per domain in policy
decision = composite ≤ threshold(action) → ALLOW
> threshold(action) → DENY | ESCALATE§4 — Policy Evaluation
Hybrid PDP model
Policy authoring is centralized; policy evaluation is distributed. This separates the human governance workflow (write, review, approve, version) from the performance-critical path (evaluate in milliseconds, near the resource being accessed).
Central Policy Authoring
Git for policy
Policies are written in a declarative language (OPA-compatible Rego), reviewed via pull request, approved by policy owners, and merged to a versioned policy repository. Every change is attributed, diffable, and rollback-ready.
- PR-based policy review workflow
- Semantic versioning (major = breaking)
- Automated policy linting & testing
- Signed commits for non-repudiation
Distributed PDP Cluster
Evaluate near resources
Policy Decision Points run co-located with resources or within the same network region. Each PDP subscribes to the policy repository and maintains a hot copy of the relevant policy bundle. No round-trip to a central server on the evaluation path.
- Pull-based policy sync (< 30s lag)
- Stateless evaluation, horizontally scalable
- Local cache for recent decisions
- Signed decision artifacts with PDP identity
Trust Evaluation Service
Separate from business logic
A dedicated service that holds no business logic — only trust state. It maintains the delegation registry, tracks lineage depth, computes trust risk scores, and holds the revocation index. Deliberately isolated so it can be audited and operated independently.
- Delegation chain registry
- Real-time revocation propagation
- Anomaly detection (volume, time, source)
- Independent audit log, separate key
§5 — Decision Artifacts
Decision artifacts
Every authorization decision produces a structured artifact that is signed by both the PDP and the Trust Evaluation Service. The artifact is the atomic unit of the audit trail — self-contained, replayable, and verifiable without access to the original infrastructure that produced it.
Signed
Dual signatures from PDP and Trust Evaluation Service. Forgery requires compromising both, which are operated independently.
Replayable
Contains all inputs needed to re-run the decision: request, context snapshot, policy reference, and risk scores.
Auditor-ready
Structured to answer the questions auditors actually ask: who, what, when, why allowed/denied, under which policy version.
Append-only
Artifacts are emitted to a hash-linked log. Retroactive modification is detectable. No delete operation exists.
Example — decision artifact (application/agf+json)
spec: agf/decision/1.0{
"artifact_id": "da_01JBXK4M9P2QR8STUVWX",
"spec_version": "agf/decision/1.0",
"timestamp": "2026-06-15T09:41:22.104Z",
"agent": {
"id": "did:agent:acme:billing-automation-v3",
"session_id": "sess_9f2kMnPqRs",
"delegation_depth": 2,
"parent_agent": "did:agent:acme:finance-orchestrator-v1"
},
"request": {
"action": "stripe.charge.create",
"resource": "urn:acme:customer:cust_8XpQ4rZnKv",
"context": {
"source_ip": "10.0.1.45",
"hour_utc": 14,
"request_volume_1h": 12,
"initiating_user": "did:user:acme:alice@acme.com"
}
},
"risk": {
"inherent": 0.72,
"environmental": 0.08,
"trust": 0.19,
"composite": 0.51,
"threshold": 0.80,
"within_threshold": true
},
"decision": "allow",
"conditions": [
"amount_usd <= 10000",
"currency in ["USD", "EUR"]"
],
"policy": {
"id": "pol:acme:billing:charge-auth",
"version": "4.2.1",
"pdp_id": "pdp-us-east-1-7f3a",
"evaluated_at": "2026-06-15T09:41:22.098Z"
},
"signatures": {
"pdp": "Ed25519:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"trust_service": "Ed25519:z6Mkf5rGnVmCKV4E5HGnZqPLbWqAgHgakornCk3MJnCHGfsR"
}
}The risk block records all three risk layer scores and the composite result so auditors can understand exactly why the decision was ALLOW or DENY without re-running the evaluation. Thepolicy.versionfield pins the exact policy version that was active at decision time, enabling replay against any future policy changes.
This specification is in active development.
Working group participation is open. Feedback on any section is welcome via GitHub.