Policy narrows the permission to act.
Define the envelope around an authorized action without treating a rule as a source of authority.
- Attributable principal
- Valid authority origin
- Current policy and trust
- Enforceable action decision
A policy envelope is multidimensional
A principal may be authorized for a task but still face conditions on how it acts. A policy envelope can limit permitted actions, tools, systems, data, amount or value, geography, time, counterparty, purpose and operating state. An approval requirement can route higher-risk requests to a person rather than granting silent execution.
A financial agent might be authorized to prepare a payment to a known supplier, but policy can cap amount, require a verified counterparty and prohibit release outside a working window. A maintenance agent might hold repair authority while a plant is in maintenance mode, but not while a safety interlock is active.
- Action and tool
- System and data
- Amount or value
- Geography and counterparty
- Time and purpose
- Operating state and approval
Policy cannot manufacture authority
The order matters. First establish an authority origin and valid delegation. Then test whether the requested action fits policy. A policy rule saying “payments below $10,000 are allowed” cannot give payment authority to a principal that was delegated only invoice review.
This distinction prevents configuration drift from becoming accidental privilege. Adding a broader policy condition should not widen a child grant or bypass its parent chain. The effective permission is the intersection of valid authority and all applicable constraints.
Operational policy changes
Policies change when risks, tasks or operating conditions change. A runtime decision should use the applicable version and context, and the evidence record should identify which policy governed the decision. Operators need a way to see why a request would be allowed, denied, escalated or degraded.
The ProofGrid model treats policy as a control layer around delegated authority. Specific syntax and management interfaces are evolving and are not presented here as a shipped public configuration language.
Write policy around the protected operation
A policy should describe the operation the execution system can actually perform. “Manage cloud” is a poor boundary; “restart service S in environment E during incident I” can be evaluated. The target object, action type and task purpose should travel to the decision point in a trustworthy form. If the tool only reports a generic operation after execution, it is too late to enforce a meaningful envelope.
Some dimensions interact. A payment under a numeric ceiling may still be impermissible for a new counterparty. A maintenance action within a time window may still be unsafe during an active alarm. The decision must evaluate the intersection of applicable constraints rather than selecting whichever rule is easiest for the agent to satisfy.
Test denial and escalation before launch
Design reviews often test the happy path and postpone failure semantics. For each consequential action, exercise an absent grant, a revoked parent, a stale signal, a missing approval and an execution-system timeout. The expected result may differ by risk, but it must be explicit. A policy that silently defaults to allow when context is missing is not a reliable boundary.
Policy changes also need provenance. If an operator narrows a limit during an incident, the next action should use the new rule, and the decision record should identify it. If the rule broadens, the underlying grant still caps what the principal may do. This separation keeps policy administration from becoming a hidden route for increasing delegated authority.
Platform / Next Step