Most AI agents fail the same way. A model reads a file, or a web page, or a tool result, and treats what it read as an instruction. A line inside a README can ask the agent to send a key somewhere, and the agent complies, because nothing in the system distinguishes data from command.
We treat that as a design flaw, not a prompt-engineering problem.
Three places authority lives
In Beyonders, authority lives in exactly three places, and nowhere else.
- Local tool authority in Directioner-CLI, for work inside a repository you granted.
- Cloud action authority in the backend, for account and task operations.
- Privileged machine authority in Directioner-OS, for changes to the system itself.
A repository, a tool result, a file, a model response: each can inform a decision. None of them can authorise an action. Text is never authority.
Capabilities, not shell
When the AI does act, it does not open a shell and improvise. It calls a typed, versioned capability such as package.install or service.restart. Every token is short-lived, scoped to a plan and revocable. The control plane never shells out to root.
That boundary is enforced independently of the model. Even a fully compromised model cannot exceed the capabilities it was granted, because the grant is checked outside it.
Gates by blast radius
Each step is scored for how much it can damage, then routed to one of four gates: auto-allow, notify-after, confirm-before, or expert-review. Changing authentication, networking or privilege cannot skip to a lower gate; it requires a security review first.
A single kill switch revokes every capability token and halts background activity, whether or not the AI control plane is responsive.
What this does not promise
We do not claim the system is unhackable, or that nothing will ever go wrong. The claim is narrower and more useful: authority is bounded, failure is constrained, recovery is safe, and status is truthful. That is what we are building toward, and we will describe it as done only when it is.