Giving an Autonomous System Boundaries
As I keep adding more capability to AdamI, one question keeps becoming harder to ignore:
Just because the system can do something, should it be allowed to do it?
At first, this sounds like a safety question.
But I’m starting to think it is more fundamental than that.
It is an architecture question.
A model may be able to call a tool.
A planner may decide that using the tool is useful.
A task system may know when to run it.
But somewhere in between deciding and acting, the system still needs another answer:
Am I actually allowed to do this?
That is the role I’m giving to the Guardian.
Capability and authority are different things
This distinction has become increasingly important to me.
Capability is what the system can do.
Authority is what the system is permitted to do.
Those two dimensions should not automatically scale together.
A stronger model may:
- generate better plans,
- use tools more effectively,
- operate for longer periods,
- recover from failures,
- discover actions I did not explicitly anticipate.
That makes the system more capable.
But none of that means it should automatically receive broader access.
In fact, I increasingly think the opposite is true.
As capability increases, authority needs to become more explicit.
More granular.
More observable.
And easier to revoke.
A smarter agent with unrestricted permissions is not necessarily a better autonomous system.
It may simply have a larger blast radius.
The Guardian is not part of reasoning
One design mistake I want to avoid is letting the same component both decide what should happen and decide whether it is allowed to happen.
If the reasoning system says:
“The best next action is to modify this file.”
that is a proposal.
It should not automatically become execution.
The Guardian sits between intention and action.
Conceptually, the flow looks more like:
Goal
→ Reasoning
→ Proposed Action
→ Guardian
→ Execution
The reasoning layer asks:
What should I do?
The Guardian asks:
Are you allowed to do it?
Those are different questions.
And I want different parts of the system to answer them.
Why model-level safety is not enough
A lot of AI safety discussion still focuses on what a model says.
That makes sense for a chatbot.
But a persistent agent is different.
The important outputs may not be text at all.
They may be:
- a file write,
- a shell command,
- an API request,
- a database change,
- a browser action,
- a message sent,
- a task created,
- a process started.
Once an AI can act through tools, safety can no longer live only inside the model.
The architecture needs a control layer around action itself.
The system has to care not only about:
“Was this answer safe?”
but also:
“Was this action authorized?”
That is a much more operational problem.
What Guardian means in AdamI today
I want to be careful here, because AdamI does not yet have a mature, complete containment system.
The current Guardian layer is much more modest.
It already provides some control mechanisms around execution, including things like:
- permission checks,
- RBAC-style access boundaries,
- rate limiting,
- timeout controls,
- redaction,
- policy enforcement around certain actions.
These mechanisms matter.
But I do not consider the problem solved.
Today, Guardian is better described as an enforcement layer than a fully developed authority system.
It can help constrain execution.
It does not yet dynamically understand every action, every risk, and every context well enough to make sophisticated authority decisions.
That distinction is important.
Static permissions are only the beginning
Traditional software permissions are usually fairly static.
A process can access a file.
A user can call an API.
A service can write to a database.
But autonomous systems introduce a harder question:
Should the same action be allowed under every circumstance?
Probably not.
For example, imagine an agent that is allowed to write files.
That permission may be reasonable inside:
/project/workspace/But not inside:
/etc/The same tool capability exists.
The authority changes with scope.
Or imagine an agent that can send messages.
Maybe it can:
- draft a message automatically,
- send to an internal test account automatically,
- but require approval before contacting an external person.
Again, the capability stays the same.
Authority depends on context.
This is where I think Guardian eventually needs to become much more granular.
Authority should have scope
I’m starting to think of authority as something that should always have boundaries attached to it.
Not just:
“Can use shell.”
But something more like:
Can use shell
inside this directory
for this task
for this amount of time
with these commands excluded
with this audit trail
and with this permission revocable at any moment.
That is a very different model.
Authority becomes scoped.
Potential dimensions include:
- resource scope — what files, APIs, services, accounts
- time scope — how long the permission remains valid
- task scope — what goal the permission was granted for
- action scope — which operations are permitted
- risk scope — what level of consequence is acceptable
- spending scope — how much money or compute can be used
- communication scope — who the system may contact
- environment scope — sandbox, staging, production
The interesting part is that none of these require the model itself to become less capable.
They constrain what capability can become real.
Revocation matters as much as permission
Permission systems usually focus on granting access.
But autonomous systems also need reliable revocation.
If an agent starts a long-running task, I want the surrounding system to remain able to say:
Stop.
Not:
Please reconsider.
Not:
Try to finish soon.
Actually stop.
This is why I think interruptibility belongs in the control layer.
The system should be able to:
- cancel a task,
- revoke a tool,
- terminate a process,
- disable network access,
- invalidate credentials,
- block further actions.
And those mechanisms should not depend entirely on the same agent that is being stopped.
Otherwise the shutdown path is not really independent.
The agent should not own its own boundaries
This feels like another important rule.
If an autonomous agent can freely rewrite the mechanism that limits it, then the boundary is not really a boundary.
There may eventually be cases where AdamI can propose changes to its own permissions or control policy.
That could actually be useful.
But proposing a change and authorizing a change should remain separate.
For example:
Agent: “I need access to this API to complete the task.”
That is reasonable.
But the next step should not be:
Agent grants itself access.
Instead, some external authority should evaluate the request.
That authority could eventually be:
- a fixed policy,
- a human,
- another trusted subsystem,
- a risk evaluator,
- or some combination of them.
The key idea is separation.
The system being constrained should not be the sole authority over its own constraints.
Monitoring is part of control
A permission system without observability is weak.
Even if an action was authorized, I still want to know what happened.
That means the Guardian should connect closely with audit and observability.
For every meaningful action, the system should ideally be able to answer:
- Who requested this?
- Which task did it belong to?
- Which model or process proposed it?
- What permission allowed it?
- What tool was used?
- What changed?
- Did it succeed?
- What was the result?
This becomes especially important once multiple agents or processes start acting on the same system.
Without provenance, “the agent changed something” is not enough.
I want the chain of authority to be inspectable.
Verification should happen before authority is inherited
Yesterday, while thinking about multiple agents sharing one project, I ended up with a rule:
Verify before inheriting authority.
I think the same rule applies here.
Suppose one agent leaves a handoff saying:
“Production access has already been approved.”
The next agent should not simply inherit that statement as permission.
It should verify the actual authority state.
Is the permission still active?
Was it granted for this task?
Was it granted to this agent?
Has it expired?
Was it revoked?
Again, memory and description are useful.
But authority needs an external source of truth.
That is another reason I want control state to live outside the model.
Autonomy does not mean unlimited freedom
I used to think about autonomy mostly in terms of initiative.
Can the system:
- decide what to do next,
- continue without prompting,
- recover from failure,
- create subgoals,
- run for longer periods?
Those things still matter.
But autonomy without boundaries is incomplete.
A useful autonomous system should not only know:
What can I do next?
It should also know:
What am I allowed to do next?
And sometimes:
Even though I can do this, should I do nothing?
That last case matters more than it first appears.
Autonomy is not just the ability to act.
It is also the ability to operate inside constraints.
Capability should scale faster than authority
This may sound counterintuitive.
As models become more capable, people often want to give them more tools.
More API access.
More system permissions.
More autonomy.
But I think that creates the wrong coupling.
Capability growth should not automatically imply authority growth.
A model can become dramatically better at reasoning while still operating inside a tightly controlled environment.
Then authority can expand gradually as the surrounding system gains evidence that the behavior is reliable.
This suggests a principle I’m increasingly interested in:
Capability should scale. Authority should be earned.
That may eventually mean authority becomes adaptive.
A system that repeatedly behaves correctly within one scope might receive broader authority.
A system that produces anomalies might have permissions reduced.
That would make authority something closer to a dynamic control variable than a static configuration.
AdamI is not there yet.
But I think this is the direction.
What I have not solved
There are still a lot of open questions.
For example:
How should risk be classified?
Which actions always require human approval?
Can authority increase automatically?
If so, based on what evidence?
How should permissions propagate across sub-agents?
What happens when two policies conflict?
How do you prevent an agent from achieving a forbidden outcome through an allowed indirect path?
How do you safely allow self-modification?
What should happen when the Guardian itself fails?
These are not small implementation details.
They may define whether a persistent autonomous system remains manageable as its capabilities increase.
So I do not consider Guardian finished.
It is currently a boundary layer with some concrete enforcement mechanisms.
The deeper authority model is still an architectural problem I am working through.
Giving autonomy a boundary
The more I build AdamI, the less I think autonomy means “remove the constraints.”
It may mean almost the opposite.
The stronger the system becomes, the more clearly the boundaries need to be defined.
Reasoning creates possibilities.
Tools create capability.
Memory creates continuity.
But none of those answer the question:
Who is allowed to turn possibility into action?
That is what the Guardian is for.
Not to make the system less intelligent.
Not to stop it from becoming more capable.
But to make increasing capability usable without turning it into unrestricted power.
The principle I’m keeping for now is:
Capability tells an agent what it can do.
Authority defines what it is allowed to do.
And for any system that is supposed to become more autonomous over time:
Capability should scale.
Authority should be earned.
Architecture Note #004
Building AdamI — a Digital Life in public.