Most organizations begin AI governance too late. They ask whether AI can perform a task, then connect it to real systems and discover the harder question: What is the AI actually allowed to do without a person?
That question creates what I call the Action Boundary: KNOW → RECOMMEND → CHANGE → RELEASE. Capability does not determine authority. The boundary does.
Four boundaries. Four different rights.
| Boundary | AI may… | Core question |
|---|---|---|
| KNOW | Retrieve, read, summarize and maintain context. | What information may it treat as evidence? |
| RECOMMEND | Analyze, draft, rank and propose. | How visible are evidence and uncertainty? |
| CHANGE | Modify internal state, records, files or workflows. | What authority does it have to write? |
| RELEASE | Commit an externally consequential action. | Who owns the decision and consequence? |
A system may read an account record but not change it. It may draft an email but not send it. It may recommend a price but not commit the company to it. It may prepare a contract but not execute one.
Around that boundary sits an operating layer:
Not tools. A governed system.
Capability is not authority.
Agentic AI creates a tempting question: Can the AI do this?
Can it research? Write? Browse? Modify files? Update databases? Create code? Send messages?
Increasingly, the technical answer is yes.
But organizations already understand that capability and authority are different things. A salesperson may technically be able to change an approved price. That does not mean the organization authorizes it. A developer may technically be able to delete production data. That does not mean deletion belongs inside their operating rights.
Capability describes what execution is possible. Authority describes what execution is permitted.
KNOW: before an agent acts, it forms some version of reality.
What account is this? What happened previously? Which policy applies? Which source is current? Which facts are confirmed? Which remain assumptions?
That means the first boundary exists before visible action. It is the knowledge boundary.
An AI may retrieve information, search approved material, maintain context and summarize records. But read-only access does not eliminate risk.
A structured source can still be stale while a more recent piece of evidence says something different.
More context is not automatically better grounding. If sources conflict, the system needs a way to distinguish authority, recency and uncertainty.
- approved sources
- provenance
- recency
- source hierarchy
- visible uncertainty
- conflict handling
Grounding needs source hierarchy.
What if two trusted sources disagree? What if the structured system is stale? What if yesterday’s interpretation has already been written into today’s record?
Grounding without source hierarchy can simply provide more material for confident inference.
The operating system therefore needs to preserve not only information, but information state: Verified. Historical. Unresolved. Hypothesis. Approved. Expired.
RECOMMEND: useful AI can remain advisory.
At RECOMMEND, the AI may analyze, compare, prioritize, classify, draft or propose a next move.
Signal 015 tested this through three account-preparation runs. The first produced a fast, polished recommendation that compressed facts, history, uncertainty and interpretation into one narrative. The second forced the system to separate verified facts, internal history, unresolved questions and hypotheses before recommending anything. The third allowed compression only after that state had been reconciled.
Otherwise the system is not supporting judgment. It is replacing uncertainty with presentation quality.
Recommendation is not decision.
A recommendation may be well written, well structured and completely wrong. The quality of the prose cannot become a proxy for authority.
A useful recommendation should make it possible to ask: What evidence supports this? What conflicts with it? What remains unknown? What would cause the recommendation to change?
CHANGE: now the system starts altering the environment.
An agent crosses CHANGE when it can update a CRM field, modify a file, change a database record, create or assign a ticket, alter workflow state, update a forecast, modify code or trigger another system.
This is where identity and authorization become infrastructure.
If an AI changes something: Who changed it? Under whose authority? Based on what evidence? Was the action inside scope? Can it be reversed? Can a person reconstruct why it happened?
Long chains create propagation risk.
Microsoft Research’s DELEGATE-52 benchmark tested long delegated document workflows across 52 professional domains and 19 models. By the end of long workflows, roughly a quarter of document content was corrupted on average. Agentic tool use did not eliminate the degradation.
A benchmark is not a production deployment. The useful lesson is narrower: as action chains grow longer, small errors gain more opportunities to propagate.
Microsoft Research / arXiv 2604.15597
Self-confirming records.
An AI reads an uncertain record, interprets the uncertainty as a conclusion, writes that conclusion back into the system, and another AI later reads the written conclusion as evidence.
Inference has converted itself into apparent fact. I call this a self-confirming record.
CHANGE can affect what the next system believes.
Separate interpretation from write authority.
I do not want one general-purpose agent to read a messy state of record, interpret it and freely rewrite the same source. Research gathers. Analysis interprets. A write capability performs specific bounded changes. Consequential changes may still require human authority.
Four dimensions move the boundary.
| Dimension | Lower-control side | Higher-control side |
|---|---|---|
| Consequence | Small local effect | Legal, financial, customer, safety or reputational consequence |
| Reversibility | Easy to undo | Difficult or impossible to reverse |
| Uncertainty | Strong evidence, clear rule | Conflicting evidence or ambiguous judgment |
| Propagation | Isolated result | Changes downstream systems or future decisions |
A low-consequence, reversible, high-confidence and isolated change may reasonably run automatically. An ambiguous action with external consequences and wide propagation deserves a harder boundary.
RELEASE: preparation becomes commitment.
Send the email. Enroll the sequence. Publish the article. Execute the contract. Spend the money. Deploy the code. Commit the price. Communicate something externally on behalf of the organization.
In my own operation, I use deliberately blunt distinctions:
Stage is not launch.
Preparation and release are different rights. An agent should not inherit release authority merely because it already has access to the tool that makes release possible.
Signal 019 was the artifact-level version.
Signal 019 introduced the Evidence-to-Action Contract: SOURCE → STATUS → SCOPE → REVIEW → RELEASE.
That contract applies to an individual artifact. The Action Boundary is the system-level architecture around the same idea.
Signal 019 asks: Is this piece of work ready to move?
The Action Boundary asks: What is this system allowed to move at all?
Governance wraps the architecture.
A single grounded capability touching consequential information may require more operating discipline than six harmless agents brainstorming ideas.
The operating layer has eight controls.
1. Identity
What system or agent is acting? Under whose authority?
2. Context
What information may it use? Which source is authoritative?
3. Authority
What can it read, recommend, change or release?
4. Evidence
Can consequential outputs be traced to supporting material?
5. Review
Where does human judgment materially improve the result?
6. Escalation
What uncertainty or consequence forces the system to stop?
7. Release
What conditions must be met before work leaves preparation?
8. Rollback
Can the action be reconstructed, reversed and corrected?
Failure modes reveal the boundary.
These are not primarily intelligence problems. They are operating-system problems.
Authority without state is dangerous.
One of my earlier multi-agent failures looked trivial. An upstream agent finished work and handed the next agent a pointer to the result. The next agent did not actually have the list, source, criteria or unresolved questions.
A downstream system should not inherit permission to act without inheriting the evidence and constraints required to use that permission correctly.
Human authority has to be real.
The organization says: A human makes the final decision.
But can the human understand the basis of the recommendation? Challenge it? Stop the action? Do they have enough time and meaningful discretion?
Agent identity is becoming infrastructure.
In February 2026, NIST published its concept paper on software and AI agent identity and authorization. By September 2026, it had received feedback from more than 600 commenters across government, academia and industry. NIST then selected DevSecOps as the first implementation use case for practical work on identifying, authenticating and authorizing agents.
If software can act, an organization increasingly needs to know what acted, under whose authority, with which permissions, against which resource, and with what resulting change.
Autonomy should be earned.
The Action Boundary should not remain permanently fixed.
A workflow may begin with every proposed action requiring approval. Then performance is measured. Failures become visible. Checks improve. Evidence quality improves. The workflow stabilizes.
Low-risk actions can move outward across the boundary. Higher-consequence actions remain gated.
And the boundary must be able to move backward. If the environment changes or errors rise, authority can contract.
Four questions replace “Can AI do this?”
| Can AI KNOW this? | Does it have appropriate, current and permissible evidence? |
| Can AI RECOMMEND this? | Can it expose enough evidence and uncertainty to support a real decision? |
| Can AI CHANGE this? | Does it have the identity, permissions, scope, reversibility and logging required to alter state? |
| Can AI RELEASE this? | Is it authorized to create the external or difficult-to-reverse consequence? |
AI may read pricing policy, recommend a price and populate a draft quote, and still have no authority to send it.
That is not inconsistency. That is governance.
Task-level, not job-level.
Authority belongs at the level of the action, not the job title.
The future governance question may be less Which jobs can AI automate? and more:
The Predicai Action Boundary
| KNOW | Retrieve, interpret and maintain context. | Source authority, provenance, recency, conflicts. |
| RECOMMEND | Analyze, draft, prioritize and propose. | Evidence, uncertainty, decision criteria, meaningful human judgment. |
| CHANGE | Modify internal state. | Identity, permissions, scope, reversibility, logging. |
| RELEASE | Commit an externally consequential action. | Authorization, consequence, accountability, release conditions. |
IDENTITY → CONTEXT → AUTHORITY → EVIDENCE → REVIEW → ESCALATION → RELEASE → ROLLBACK
Not every task crosses every boundary. Not every boundary requires a human. But every consequential system should know where its boundary is.
That boundary is the system. Everything else is capability.
NIST / NCCoE — Software and AI Agent Identity and Authorization, 2026
Microsoft Research — DELEGATE-52
Predicai Signal 013 — complete handoffs and reusable operating procedure.
Predicai Signal 015 — evidence state before recommendation.
Predicai Signal 019 — SOURCE → STATUS → SCOPE → REVIEW → RELEASE.
Predicai Signal 020 — using AI versus operating AI.
Predicai Signal 021 — review debt and the human-attention bottleneck.