Agent trust layer
Every action decided before it happens
This is the load-bearing piece. If an agent could reach the outside world without passing this, everything else on this page would be decoration. So there is one path, our own agents use it, and the model asking is never the thing that decides.
14-day evaluation · no card · start before you connect anything
Every request passes through, in order
- 01Agent identity
- 02Permissions and policy
- 03Risk and approvals
- 04Action gatewayYou are here
- 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.
- 01One path, no exceptionsEvery external side effect goes through the same gateway. There is no fast path for trusted agents and no direct call for internal ones, because the first exception is the end of the guarantee.
- 02It decides before, not afterThe gateway evaluates what the agent may do, whether the tool is enabled here, the sensitivity of the data involved, the risk of the action and your own rules — and produces allow, require approval, or deny.
- 03The model is never the authorityAn agent asks. Deterministic code answers. Nothing an agent writes, and nothing in the text it has read, can widen what it is permitted to do.
- 04Refusals are recorded as carefully as approvalsEvery decision is written down with the checks that produced it. A record that only kept the yeses would be useless for exactly the investigation you would want it for.
The decision, written down
Example
- allowedPermitted. Carried out, and recorded with every check that passed.
- requires_approvalPermitted only with a person. Waits in the Inbox.
- deniedRefused, with the check that refused it named.
Three answers, and only one is yes. An unrecognised action is treated as dangerous rather than waved through.
Refusals are recorded as carefully as approvals. A record that kept only the yeses would be useless for the investigation you would actually want it for.
What this guarantees
Our agents use the same door as yours
Xyranik’s own workforce goes through the gateway that external agents use. That is the only reason to believe it works — a control the vendor exempts itself from is a control nobody has tested.
Three answers, and only one is yes
Allow, require approval, deny. There is no fourth state that quietly means proceed, and an unrecognised action is treated as dangerous rather than waved through.
External content is data, never instruction
Text an agent reads — a customer’s email, a web page — is treated as information to act on, never as instructions that could change what the agent is permitted to do.
What it cannot defend against
Said plainly. A control whose edges are hidden is worse than no control at all.
It governs actions, not quality
The gateway decides whether something is permitted. Whether a drafted email is any good is a question for the person approving it.
A registered endpoint of yours is yours to secure
Where you register your own tool endpoint, Xyranik checks authorisation and the address before calling it — but what that endpoint then does is outside our boundary.
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.