An authority foundry is a control-plane mechanism that mints bounded authority only when the right workflow state, purpose, scope, and conditions are present.
The minimum design
A practical foundry needs a trusted workflow identity, an issuer or broker, and a small capability catalog with a compiler. The workflow identity provides explicit context such as an incident, deployment job, approval artifact, or task. The broker is the only mechanism allowed to mint the authority. The capability catalog turns intent into bounded power.
AI may help interpret a request, propose scope, or select a supported capability. It should not be the mechanism that creates arbitrary authority. The model can be the interpreter; the foundry remains the deterministic authority boundary.
A production example
Instead of giving a deployment pipeline one standing role across environments, the foundry verifies that an artifact is validated and that the workflow is in the deploy-authorized state. It then mints a short-lived token for one service, artifact, environment, and deployment window.
The pipeline cannot widen its own authority. When deployment completes, the token collapses. A new deployment requires a new valid transition and a new minting event.
The design test
Ask how a team unblocks itself. If the answer is “write or copy a new permission document,” authority is still governed mainly by review and memory. If the answer is “select a supported capability and let the platform mint the bounded authority,” the system is moving toward structural governance.
A foundry is not an approval queue. Its value comes from making the governed path fast enough to be the default under pressure.