Grant record template
Fields for issuer, holder, scope, evidence basis, expiry, revocation conditions, and state.
Hold every delegated authority as a stateful record with provenance, scope, evidence basis, expiry, revocation conditions, and state history.
Permanent link /mechanisms/patterns/authority-grant-register
Where it fits
Tagged for Governance, Policy with validator handshakes. Includes 3 steps, 3 reusable assets, and 4 snippet blocks.
Jump to
Copy citation (APA/BibTeX)
APA
Ethotechnics Institute Research Team. (2026). MEC-13 Authority grant register. Ethotechnics Institute. https://ethotechnics.org/mechanisms/patterns/authority-grant-register
MLA
Ethotechnics Institute Research Team. "MEC-13 Authority grant register." Ethotechnics Institute, 2026, https://ethotechnics.org/mechanisms/patterns/authority-grant-register.
Chicago
Ethotechnics Institute Research Team. "MEC-13 Authority grant register." Ethotechnics Institute. Jan 9, 2026. https://ethotechnics.org/mechanisms/patterns/authority-grant-register.
BibTeX
@misc{mechanism_authority-grant-register,
title={MEC-13 Authority grant register},
author={Ethotechnics Institute Research Team},
year={2026},
howpublished={Ethotechnics Institute},
url={https://ethotechnics.org/mechanisms/patterns/authority-grant-register},
version={v1.1.0}
}
RIS
TY - WEB TI - MEC-13 Authority grant register AU - Ethotechnics Institute Research Team PY - 2026 UR - https://ethotechnics.org/mechanisms/patterns/authority-grant-register ER -
Specification overview
Capture the scope, assets, and validator handshakes before diving into the steps.
Spec essentials
Filters & validators
Tagged in 2 filters with 1 linked validators.
Glossary anchors
Jump to the glossary terms that frame this mechanism.
Steps
Start with the field cues, then use the assets to keep the work legible.
3 steps with checklist-ready owners, plus linked assets for handoffs.
0 of 3 steps complete
Assets
Link or copy these assets into design docs, runbooks, and briefs so the mechanism travels with the work.
Fields for issuer, holder, scope, evidence basis, expiry, revocation conditions, and state.
The permitted moves between grant states and who may make each one.
Upcoming expiries with the reviewer responsible for each renewal decision.
Reuse-ready snippets
Use these snippets in requirements, audits, and postmortems with the mechanism permalink.
Policy requirement
Policy requirement (MEC-13 Authority grant register) - Maintain a register of delegated authorities with issuer, scope, evidence basis, expiry, and revocation conditions. - Record every grant state change with its reason and reviewer, and expose the register to the decision log. Reference: https://ethotechnics.org/mechanisms/patterns/authority-grant-register
Product requirement
Product requirement (MEC-13) - Each consequential action names the grant identifier and grant state it ran under. - Grants past expiry move to review_required and are refused until a reviewer renews them.
Audit evidence checklist
Audit evidence checklist (MEC-13) [ ] Every exercised authority has a register entry with issuer and scope. [ ] Grants carry an expiry and stated revocation conditions. [ ] State history shows who changed each grant and on what basis.
Postmortem trigger
Postmortem trigger (MEC-13) Trigger review when an action runs under a grant that is missing, expired, or not in the allowed state.
Example usage
A concrete scenario to help teams see how the pieces fit together.
How it plays out
A support platform records the agent's refund authority as a grant with a value ceiling, an evidence basis in the last accuracy review, a 90-day expiry, and revocation on any confirmed mis-refund; the refund endpoint reads the grant state before acting.
Anti-patterns
Use these to avoid superficial compliance and clarify what success requires.
Authority lives in a role file or feature flag with no issuer, basis, or expiry, so widening it is a deploy rather than a decision.
Counterfactual: Authority lives in a register where each grant names its issuer, basis, expiry, and revocation conditions.
False-positive warning: Config can still enforce the grant; the register is the record of why the config says what it says.
Grants are documented once and never move, so an expired or contested grant reads the same as a current one.
Counterfactual: Each grant carries a current state and an appended history of transitions.
False-positive warning: A stable grant is fine; what matters is that the register can show it was reviewed and left in place.
Validators
Use these tools to size risk and keep the stewardship path visible.
Validator
Evaluates AI system prompts, architectures, and automated decision logic against 80+ governance failure modes and synthesizes executable guardrail code and legal SLA clauses.