16 — Tool invocation governance.
Every tool call — from a human operator, an integration, or an agent — is mediated by the
policy decision point (PDP). The PDP is small, deterministic, and audited. Its rulings are
the gating contract between intent and effect.
16.1 PDP request shape
16.2 PDP algorithm
The PDP runs a fixed sequence. The first failing step terminates with a typed deny.
16.3 Rejection taxonomy
16.4 Dispatch-time audit
Every PDP ruling, allow or deny, is recorded as a typed AuditEvent: policy.allow or policy.deny. The record includes the request shape, the matched rule path, and the input version of the tenant policy. PDP rulings are immutable; subsequent rulings on the same input are independent records.
16.5 Agent scope minimisation
An agent definition declares its required scopes. The platform enforces the minimum: a scope not declared cannot be used at runtime, even if the principal calling the agent holds it. This prevents privilege amplification through agent invocation.
The effective permission set at any instant equals the minimum of: caller-principal grant, agent declared scopes, subject marking clearance, ABAC predicate satisfaction. Privilege never increases by traversing planes.
16.6 Policy as data
Tenant access policies are versioned data, not code. The PDP reads the active version; changes are typed AuditEvents (policy.update) on the tenant chain. Rollback is a re-promotion of a prior version.
16.7 Latency & caching
The PDP is in-substrate and synchronous. Cache keys are (principal-version, subject-marking-set, tool-id, tool-version, policy-version); cache invalidation is triggered by any of the inputs changing. The PDP target SLO is p99 ≤ 5ms.
16.8 Failure-open prohibition
If the PDP cannot reach its policy store or its principal store, it fails closed. Tools cannot dispatch; reasoning runs cannot start; commits cannot complete. This is non-configurable.
