Authority is not a prompt
Instructions describe what an agent should do. Authority defines what it is permitted to do.
A prompt can ask an agent to stay within scope, request approval or check its own work. Those instructions are useful. They are also instructions interpreted by the same system that proposes the action.
A governance boundary needs a separate source of authority. The proposed action and the permission to carry it out answer different questions.
Responsibility before runtime
In DaemonCore’s agent model, a Role describes organisational responsibility and its authority boundary. A Profile specialises how or where that responsibility is applied. A Persona shapes communication and interaction.
These dimensions are independently reusable. A more assertive Persona does not grant approval rights. A reviewer Profile does not add expertise absent from the Role.
The worker, model and project assignment are separate runtime inputs. Replacing a worker should not silently redefine the responsibility it is assigned.
The boundary must reach the action
Writing down a policy does not establish that every action is checked. An evaluation needs to inspect the actual enforcement point, its configuration and the path to execution.
Advisory mode and blocking enforcement have different consequences. A recorded admission is not evidence that the downstream work completed. These distinctions belong in the explanation, not in a footnote after a universal security claim.
Start with a concrete question
For one action, ask: who proposed it, under which responsibility, in which project, through which decision point, and with what recorded outcome?
That is a useful starting point for evaluating governed autonomy. Explore the architecture, then inspect the recorded evidence.