For as long as personal AI has existed, the agent has worn your face. You connected your accounts, and it acted on your behalf — your permissions, your name on the result, your reputation on the line. The newest access models quietly end that arrangement, and the consequence is larger than it looks.
When an agent acts as itself, it stops borrowing a human's credentials and starts holding its own. It posts under its own name, opens pull requests as its own app, queries the warehouse under a service account that belongs to it, not to you. There are good reasons for the shift — a shared channel should never become a side door into one person's private files, and when several people are steering at once there is no single human whose permissions are the right ones to borrow. But the shift does something subtler than fix a permissions puzzle. It makes the agent a party in its own right. And a party in its own right has behaviour you now have to account for.
The day the agent stopped borrowing your face
While the agent acted as you, its behaviour was, in a sense, your behaviour. If it sent a careless message, that was you being careless; the social and professional correction landed on a human who would feel it and adjust. The credential and the conscience were the same person. Acting as itself splits them apart. The credential is now the agent's. The conscience — the question of whether the careless message should have been sent at all — has nowhere to live unless you put it somewhere on purpose.
This is the part the access model is honest about not solving. It provisions the agent's accounts, maps each credential to the right compartment, blocks outbound traffic to any host an admin hasn't allowed, and records every call the agent makes under its own service accounts. All of that governs what the agent can reach. None of it governs what the agent should do with the reach — and once the agent is acting as itself, that question no longer has a human standing behind it by default.
Scope is a fence, not a conscience
A permission boundary is a fence around a field. It is genuinely valuable: it determines how much damage is even possible, and a tight fence around a powerful agent is one of the better safety investments available. But a fence has nothing to say about what happens inside it. Two agents fenced into exactly the same field will graze it completely differently — one carefully, flagging what it's unsure of; the other confidently, acting on its best guess and moving on. The fence rated them the same. The field looks very different by evening.
We reach for scope when what we actually want is judgement, because scope is the thing we know how to specify. It is binary, enforceable, auditable. Judgement is none of those — which is exactly why "just give it less access" is the reflex and "specify how it behaves" is the harder, rarer discipline. Narrowing scope reduces what can go wrong. It does nothing to improve what the agent does with what remains. Past a certain point, an agent fenced too tightly is just a chatbot with extra steps; the valuable work lives in the part of the field you deliberately left open — which is precisely the part scope stops governing.
The hours when no one is watching
All of this gets sharper because the agent no longer stops when you do. The length of a task an agent can carry on its own has been roughly doubling every few months; agents now schedule their own follow-ups and respond to events long after the person who set them going has logged off. The window in which an agent acts under its own identity, inside its granted scope, with no human in the loop, is widening. Every hour in that window is an hour where the only thing standing between the agent's access and your reputation is how the agent decides.
Audit logs help, but they are a record, not a railing. They tell you what the agent did after it has done it — invaluable for accountability, useless for prevention. By the time a questionable action lands in the log under the agent's service account, it has already happened, in your systems, with the access you granted. The thing that determined whether that logged action was the right one was decided earlier and elsewhere: in whatever specification of behaviour the agent was carrying when no one was watching. If that specification is "be helpful," you have left the most consequential hours of your agent's day to the vaguest instruction in the file.
What does the agent do with the access it was given?
This is the question the access model deliberately leaves to you, and it is a question about personality, not credentials. Does the agent, finding an ambiguity at 2am with no one to ask, pause and leave a flagged note, or pick a reading and proceed? Does it, handed a destructive-looking but in-scope action, do it because it can, or hesitate because the shape of it looks wrong? Does it ship the draft into the channel, or hold it because it isn't sure you'd want it public yet? None of those forks is an access decision. The agent has the permission either way. Which branch it takes is set by its character — and character is something you write, or something you leave to chance.
- Permissions decide what an agent can do. Personality decides what it does when it could do several things and only one is right.
- Scope is enforced by the system at the boundary. Judgement is carried by the agent into the part of the boundary you left open on purpose.
- An audit log tells you what happened. A soul spec changes what happens, before it reaches the log.
- The wider the autonomy window — the longer the agent runs unsupervised — the more of the outcome is decided by character rather than by scope.
So the right response to an agent that acts as itself is not only to fence it well — though you should — but to write the half of its identity the fence can't hold. Specify where it defaults to caution. Name the actions it should refuse even when it has the keys. Tell it which surprises you never want and which questions are always worth asking. That specification is not user experience or polish. With an autonomous agent acting under its own name, it is the safety layer — the one that operates in the hours when the only thing in the room is the agent and its access.
“A fence decides how much can go wrong. It says nothing about what the agent does inside it. When the agent acts as itself, unsupervised, that inside is the whole game — and it is written in soul.md, not in the access list.”
An access model fences your agent. AgentSoul specifies how it behaves inside the fence — the defaults, the refusals, the failure modes — in the four files you drop into any harness. **[Forge a soul →](/forge/)**