Agent trust layer
Deny by default, in rules you can write yourself
Permission systems fail in two ways: they default to open, and they can be evaded by leaving a detail out. Both are closed here, and the second one matters more than it sounds.
14-day evaluation · no card · start before you connect anything
Every request passes through, in order
- 01Agent identity
- 02Permissions and policyYou are here
- 03Risk and approvals
- 04Action gateway
- 05Tenant isolation
- 06Prompt-injection defence
- 07Credential protection
- 08Audit and decision ledger
- 09Kill switch
Uncertainty at any step resolves to a refusal or to asking a person — never to proceeding.
How a request is decided
Where this sits in the loop
Approve is your step. You decide. It follows Plan and hands on to Execute.
- 01Nothing is granted implicitlyA new agent starts with no permissions, and a newly added tool is not automatically available to anything that already exists. Capability is always something somebody turned on deliberately.
- 02Rules in the words you would useAsk me before an ad budget rises by more than a fifth. Never let an agent take more than a hundred people’s details at once. These are rules the engine evaluates, not guidance in a prompt.
- 03A missing fact is a refusal, not a passIf a rule is about an amount and the request does not state the amount, the request is refused. Otherwise omitting a detail would be the reliable way around every rule you wrote — which is exactly how policy engines get defeated in practice.
- 04A rule can only narrowRules restrict what an agent may do. No rule can grant an agent more than its own identity already allows, so writing one can never accidentally widen access.
A rule, and a request it refused
Example
“Ask me before an ad budget rises by more than 20%.”
Raise by 12% — allowed, and recorded.
Raise, amount not stated — refused. The rule is about an amount, and the request did not carry one.
Leaving the figure out is not the way around a rule. A request that omits what a rule is about is refused, not waved through.
What this guarantees
Rules you can read back in plain English
Each rule renders as the sentence it enforces, so reviewing your own policy does not require reading a configuration format.
Roles checked on the server
Owner, admin, member and viewer are enforced where the change happens, not in the browser. A viewer who finds the URL still cannot change anything.
Standing permissions are bounded and revocable
Where you grant something ongoing, it is scoped and can be withdrawn, and the withdrawal takes effect for work not yet carried out.
What it cannot defend against
Said plainly. A control whose edges are hidden is worse than no control at all.
No per-person approval routing
Anything needing approval goes to whoever holds the role, not to a named reviewer or a chain of them.
No organisation-wide two-factor requirement
Each person can turn on an authenticator code and it is enforced on the server. What does not exist is an admin switch making it compulsory — and a switch claiming to enforce something the server did not check would be worse than none.
Every control, and what is not built
The security page lists each control as something you can check in the product, and lists separately what is not in place — including that Xyranik holds no certification and has had no external audit.