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.
The same controls produce the records your ISO 27001, GDPR, HIPAA and EU AI Act obligations ask for.
4 tiers + 7 grants 6 audit tables · 180d 6 actions × 5 risks ISO/IEC 27001:2022 certified
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 holds one of four tiers: Member, Builder, Admin, Super Admin. A tier is how much you reach. A grant is a slice of Admin handed to someone who is not one. No one gets admin rights just because they needed to read the audit log.
Role catalogue · 4 tiers + 1 cross-org
Distributor Admin
AI Cloud mode only. Organisation lifecycle, GPU allocation, billing and cross-organisation user administration.
Super Admin
The top of an org. SSO configuration, user deletion, audit export, and the only tier that can create another Super Admin.
Admin
Control Room. Providers, knowledge, guardrails, environments, analytics, users and agent management.
Builder
Studio zone. Build agents, workflows and prompts. Launch workspaces and fine-tuning inside team quotas.
Member
Default role. Workroom and Marketplace. Use agents, browse templates. No build or admin access.
Seven additive grants · a slice of Admin 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, /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.
Katonic's own certification. Scope: development, release and support of the platform. Certificate on request. Inside your deployment, the same controls give your ISMS evidence for A.5.15 and A.5.18 access control, A.8.15 logging and A.5.36 compliance with policies.
The platform runs in your environment and you remain the controller of the data it processes. Article 5 data minimisation via PII redaction rails. Article 17: subject erasure for analytics and ledger records, per-organisation deletion at offboarding. Article 30: the append-only audit ledger as records-of-processing input.
Obligations attach to the AI systems you build and run, as provider and deployer. The platform is the control and evidence layer for them: record-keeping (Art. 12), human oversight (Art. 14), data governance (Art. 10), technical documentation (Art. 11), post-market monitoring (Art. 72).
Certifies an organisation's AI management system, not a product. Katonic is not certified. The platform keeps the inventory of AI systems, their versions, approvals and interaction records that an ISO 42001 audit of your organisation asks for.
Deployable inside a covered entity's own infrastructure. HIPAA safeguards remain the customer's, supported by the platform's access control, audit ledger and encryption at rest.
The MODON AI Centre of Excellence runs in-kingdom in line with NDMO data-management requirements (public case study). Katonic holds no NDMO status of its own.
Katonic provides the control evidence: SSO configuration, role definitions, service mesh policies, audit schemas and exported traces. The customer holds the attestation. See the Trust Center for what is on record.
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?
No vendor can hand you compliance. What the platform gives you is the evidence: SSO config, role manifests, service mesh policies, audit schemas and exported traces, all from your own deployment. What Katonic itself holds is one certification, ISO/IEC 27001:2022, listed in the Trust Center.
How does this not become a permission management nightmare?
Four tiers handle most cases. Seven 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.
4 role tiers + 7 additive grants. 6 audit tables across 2 destinations. 6 policy actions × 5 risk levels. Eval-gated promotion. Exportable evidence for the frameworks you answer to. 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. The Trust Center lists what is on record: the ISO/IEC 27001:2022 certificate, role manifests and audit schema documentation.
Audit-ready from day one. Your first compliance review will not include surprises.