Ready to get started?
Deploy sovereign AI on your infrastructure - in weeks, not months.
Platform · Trust · Governance · Identity, audit, policy
Identity that scales. An audit trail that survives the regulator's request. Tool-call policy that fires inline, not after the fact.
Same controls map to ISO 27001, GDPR, HIPAA, EU AI Act and beyond.
8 RBAC levels 6 audit tables · 180d 6 actions × 5 risks 8 framework mappings
A page in the admin console that says "RBAC enabled." A toggle for "audit logging." A vendor compliance report that covers their corporate IT, not the platform you'll deploy on. None of that helps in a real review. What does: an enforcement architecture that reviewers can trace from policy definition through tool call to audit record.
Identity decides who can ask. Policy decides what they can do. Audit records what happened. The three meet at the governance proxy: a single inline checkpoint between the agent and every external system, evaluating the request against all three before it executes.
How a tool call gets evaluated · annotated
Every user falls into one of eight role levels. Additive grants let super admins delegate narrow capabilities to specific people without promoting them. No one gets admin rights just because they needed to read the audit log.
Role catalogue · 7 in-org + 1 cross-org
Operator
Distributor console, org lifecycle, GPU allocation, billing, cross-org RBAC. Telco staff only in AI Cloud mode.
Super Admin
SSO config, user deletion, audit export, grant management. The top of an org.
Org Admin
Control Room. Providers, knowledge, guardrails, users, analytics, environments, agents management.
Builder
Studio zone. Build agents, workflows, prompts. Launch workspaces and fine-tuning inside team quotas.
Power User
Workroom premium. Deep research, personal knowledge, personal agents. No Studio or Control Room.
Member
Default role. Workroom and Marketplace. Use agents, browse templates. No build or admin access.
Viewer
Workroom read-only. View conversations but not create them. Often used for auditors or contractors.
Five additive grants · narrow capability without role promotion
Cross-team analytics live in a shared audit store and never see prompts or PII. Full-fidelity audit records, including credential values and flagged content, land only in your team's private store. You cannot correlate sensitive content across teams because the shared layer doesn't hold it.
Event flow · where each thing lands
Policies live at /policies. Audit at /audit. RBAC at /users. Click any of the three to see what your CISO sees on day one.
Policies
Tool-call governance. 6 actions · 5 risk levels · priority-ordered. Match by tool, scope, risk.
Active policies
6
of 7 configured
Decisions / hour
1,891
last 1h
Block rate
0.31%
of decisions
Pending approvals
3
median age 4m
| Policy | Scope | Min Risk | Action | Priority | Hits (1h) | Status |
|---|---|---|---|---|---|---|
| 🛡Block High-Risk Tools | All tools | high | Block | 10CRITICAL | 47 | ● ENABLED |
| ✓Require Approval · Data Deletion | * / delete_* | high | Requires Approval | 20CRITICAL | 12 | ● ENABLED |
| ⚡Rate Limit · External APIs | External tools | medium | Rate Limit | 40HIGH | 184 | ● ENABLED |
| 👁PII Scan · Customer Tools | salesforce / * | any | PII Scan | 50NORMAL | 1,247 | ● ENABLED |
| ▱Redact Output · Finance Reports | finance_db / query | any | Redact Output | 60NORMAL | 89 | ● ENABLED |
| ≡Monitor New Tool · Slack Send | slack / send_message | low | Log Only | 90LOW | 312 | ● ENABLED |
| ✓Allow · Read-Only Knowledge | knowledge / search | low | Allow | 95LOW | 0 | ○ DISABLED |
ℹLower priority numbers run first. Each tool call evaluates policies top-to-bottom; the first match wins. Block rules typically sit at priority < 30.
/policies, /audit, and /users render this in your sandbox today.Katonic ships the controls. The customer operates them inside their own authorization boundary. Below is how the same governance architecture lines up against the frameworks procurement will ask about.
A.9 access control via 8-level RBAC + grants. A.12 operations security via per-org isolation + NetworkPolicy. A.18 compliance via exportable audit.
Article 5 data minimization via 13-entity PII redaction. Article 17 right to erasure via per-org data deletion. Article 30 records of processing via immutable audit.
164.312(a) access control via SSO + audit-log grant. 164.312(b) audit controls via shared store + your private store. 164.312(c) integrity via service mesh mTLS + signed images.
Article 12 logging and traceability via trace IDs. Article 14 human oversight via HITL approvals. Article 26 documented governance for high-risk systems.
In-kingdom processing via sovereign on-prem deployment. Data classification via per-team knowledge ACLs. Audit residency via in-region private store.
Circular 982 IT risk via silo isolation + mTLS. Circular 1021 outsourcing via zero-data-egress deployment. Audit exportable to BSP-compliant format.
Air-gap capable deployment aligns to High baseline control families AC, AU, SC, SI. Customer operates in their authorization boundary; Katonic provides controls.
Katonic provides the control evidence: SSO configuration, RBAC definitions, service mesh policies, audit schemas, pen test reports, and control mappings. The customer holds the attestation. See the Trust Center for the full evidence catalogue.
An agent version cannot promote from dev to test, or test to prod, if its eval score drops below the threshold your team has set. Promotion copies config; target environments run their own ingestion. Rollback re-points the active version pointer in one click. Every promotion writes to the admin actions audit.
Promotion lifecycle · annotated
Where do tool-call decisions live?
Sanitized policy decisions in the shared audit store for analytics (180d retention). Full request context in your team's private store (configurable retention). Trace IDs link them. Exportable to your SIEM via Kafka, Webhook, or scheduled export.
Can I show a regulator the controls?
Yes. Each of the eight framework mappings includes the documented control evidence: SSO config, RBAC manifests, service mesh policies, audit schemas, pen test reports. The Trust Center holds the live evidence catalogue.
How does this not become a permission management nightmare?
Eight role levels handle 95% of cases. Five additive grants cover the long tail without role escalation. Wildcard policy matching means you don't write a policy per user; you write one per pattern (tenant, team, server, tool, risk).
Can you reconstruct an incident?
The trace_id ties an agent session to the LLM calls, the tool calls, the rail decisions, and the policy verdicts that fired during it. Plus the admin actions audit holds every config change. End-to-end reconstruction is single-query.
Your audit lives next to theirs.
The vendor's audit log is a shared multi-tenant table. Their compliance posture is their compliance posture, not yours. Audit export is a feature ticket. Cross-tenant data residency is a sales conversation.
You become the governance team.
Build SSO integration, write the audit schema, design the policy DSL, build the eval gate enforcer, build the dual-destination logging. Months of platform engineering before the first audit.
Three pillars, day one.
8-level RBAC + 5 additive grants. 6 audit tables across 2 destinations. 6 policy actions × 5 risk levels. Eval-gated promotion. Mappings to 8 compliance frameworks. Live in your auth boundary.
The compliance review will not ask whether you have governance. It will ask whether you can prove it. The first question is RBAC. The second is the audit. The third is the policy decision record. The fourth is whether all three reference the same trace ID. If you cannot answer those, the platform did not ship governance. It shipped a settings page.
Sandbox access in 24 hours. Trust Center evidence catalogue including pen test reports, control mappings, RBAC manifests, and audit schema documentation.
Audit-ready from day one. Your first compliance review will not include surprises.