Trust · Access controls
The same enforcement principle that Xybern applies to AI agents, every action verified, every access bounded, every decision recorded, applies to the humans and systems accessing Xybern itself. Access control is not a separate policy. It is the same architecture.
The AI agent access problem
A human user logs in once, completes a task, and logs out. An AI agent calls your systems thousands of times per hour and has no natural pause point where a human would notice something is wrong. Standard RBAC and API key scoping are necessary but not sufficient. You also need cryptographic agent identity, authority boundaries, and behavioural baseline tracking. Xybern provides all three.
Role-based access
Xybern's RBAC model covers both the humans administering your AI governance infrastructure and the AI agents operating within it. Every role, human or agent, has a defined permission scope. Every action outside that scope is rejected and recorded.
Full workspace control. Billing, security settings, and member management. The only role that can modify workspace-level security configuration or delete the workspace.
Manage projects, rules, policies and team members. Cannot modify billing or workspace-level security settings. The standard role for the team member responsible for configuring AI governance policies.
Run verifications, create rules, and export reports. Cannot manage members or modify security settings. The standard role for the team actively working with enforcement data.
Read-only access to verification results, vault entries and reports. Cannot run verifications, create rules or manage any settings. Designed for compliance officers and auditors who need to review without acting.
The AI agent role — different by design.
An AI agent connecting via API key has its own permission scope, distinct from all human roles. It can trigger enforcement evaluations and receive enforcement decisions. It cannot view other agents' history, modify policies, export vault entries, or access any workspace configuration. An agent that attempts any of these actions receives a hard 403, the access log records the attempt permanently.
Permission matrix
No implicit permissions. No inherited access. Every action in Xybern is explicitly mapped to the roles that can perform it. If a role is not in the Allow column, the action returns a hard rejection, not a soft error.
| Action | Owner | Admin | Editor | Viewer | AI Agent |
|---|---|---|---|---|---|
| Manage workspace | |||||
| Manage members | |||||
| Configure policies | |||||
| Run verifications | |||||
| Trigger enforcement | |||||
| View vault entries | |||||
| Export audit evidence | |||||
| Modify API keys | |||||
| View other agents' history | |||||
| Modify own agent config |
Allow — full access Restricted — requires admin approval or view-only — hard 403, attempt logged
API key scoping
Every API key issued by Xybern is scoped to specific operations, a specific workspace, and a specific expiration window. A key issued to an AI agent can only call the endpoints that agent needs. It cannot call vault endpoints, policy endpoints, or admin endpoints, even if the bearer of the key tries.
Trigger enforcement evaluations. The primary scope for AI agents.
Submit actions for verification and receive structured results.
Read vault entries for the scoped workspace. Cannot write.
Access the reasoning engine directly. Advanced integrations only.
Workspace administration. Never issue to AI agents.
Key design principle
Xybern keys use a xb_ prefix for easy identification in logs and code reviews. SHA-256 hashed storage means the raw key is never stored, only its hash.
Access audit log
The access log records every action taken in Xybern, by humans and by AI agents. It records successful actions and denied attempts equally. A compliance officer reviewing the log can see not just what was done, but what was tried and stopped. Denied attempts are as important as successful ones.
Every denied attempt is recorded permanently in the provenance vault — including the agent identity, the scope attempted, and the timestamp. The record cannot be deleted.
Key compromise response
This is the question every IT security team asks within ten minutes of any procurement conversation. We answer it here explicitly, because an inline enforcement system needs a faster and more complete answer than a generic SaaS vendor.
Detect
You identify the compromised key.
Via your own monitoring, Xybern's anomaly detection, or a direct report. The key's xb_ prefix makes it immediately identifiable in any log or code review. You have the key ID from the access log.
Revoke
Revoke instantly via API or dashboard.
One API call or one dashboard action. Revocation takes effect in under one second. All in-flight requests using the revoked key are rejected immediately, there is no grace period, no queue drain time, no delay.
Record
The revocation is recorded permanently.
The vault records the revocation event with a precise timestamp, this is the moment the key stopped being valid. You have a tamper-evident record of exactly when the compromise window closed. No backfilling. No gap.
Audit
Review everything the key did.
The access log contains every action taken by the compromised key, with timestamps, actions attempted, results, and IP addresses. Export the complete history as a Merkle-verified audit package. This is your evidence for any regulatory notification requirement.
Enforcement continuity during compromise
When a key is revoked, AI agents using that key stop being able to trigger enforcement. This means AI actions proposed by that agent will fail at the enforcement boundary, they will not execute unverified. This is the fail-closed behaviour applying to access control events, not just infrastructure events. No enforcement gap opens when a key is compromised and revoked.
No exceptions.
Deploy granular access controls, scoped API keys, cryptographic agent identity and full audit logging across your AI governance infrastructure. Every human. Every system. Every action bounded and recorded.
