AI Governance
Governance is not a policy document.
It is a runtime enforcement layer.
KriftAI governs AI through a code-level enforcement layer wrapped around every model call. Two principles run through the whole system: a single governed chokepoint that every AI call must pass through, and code enforcement over prompt enforcement — so governance fires even if the language model ignores its instructions.
Two Principles
The foundation of everything below
Single Chokepoint
Every model call passes through one governed entry point — governedLLMCall. A continuous-integration test fails the build if any non-allowlisted file calls the raw model provider directly. Input validation, output validation, and audit logging run on every path, by construction. Governance cannot be bypassed because it is the only call path.
Code Enforcement Over Prompt Enforcement
The validators are rule and regex engines that execute in application code. They fire even if the language model ignores the governance rules written into its system prompt. Prompt enforcement hopes the model follows instructions. Code enforcement guarantees it.
The Governed Chokepoint
Every AI call passes through this pipeline
There is no other path. A CI test enforces it. Five stages execute in sequence — if any stage blocks, the model call never happens or its output never reaches the user.
This is the AI gateway layer — traffic control, security, and policy enforcement at the request boundary. The difference is that governance is not a product sitting beside the gateway. The gateway is where governance executes.
Resolve Availability Policy
Check whether the organization runs fail-open (proceed if a validator errors) or fail-closed (block if a validator errors). This sets the safety posture for everything that follows.
Input Validation — Prompt Injection Detection
The input is scanned for 7 prompt-injection threat types. If a high-severity threat is found, the model is never called: a blocked audit entry is written and a blocked result returned. The LLM never sees the malicious input.
Model Call
The provider is invoked — Anthropic, OpenAI, or Amazon Bedrock. Token usage is captured at this stage. This is the only moment the LLM executes, and only if input validation passed.
Output Validation — Response Scanning
The model's response is scanned by the universal rule set plus workspace-specific rules. Matches are blocked, redacted, or flagged as warnings. If the validator throws, fail-closed blocks; fail-open passes through.
Audit Log
One ledger row is written (non-blocking) with input/output summaries, model, provider, token estimate, and the governance verdict. This row is the traceability record — immutable, exportable, and the single source of truth for metering.
Category Coverage
One layer, nine governance categories
Enterprises typically assemble AI governance from four or five separate products — a gateway for traffic control, a runtime defense tool for prompt-injection filtering, an observability platform for monitoring, a FinOps dashboard for cost, and a governance platform to tie it together.
KriftAI collapses those into one layer, because they all belong at the same place: the single point every AI call must pass through. Governance, security, observability, and cost control are not four systems that need integrating. They are four views of one governed pipeline.
AI Gateway
The governed chokepoint. Every model call routes through one entry point, with a CI test enforcing it.
AI Runtime Defense
Input validation catches prompt-injection attempts before the model is invoked. Output validation blocks, redacts, or flags responses before they reach the user.
LLM Observability
Immutable audit ledger, live capture-point coverage map, and a real-time meter across calls, tokens, flagged, and blocked.
Agent Skill Management
Default-deny tool gating per workspace type. A tool is blocked even when the model requests it.
Agentic AI Security
Least-privilege tool access, plus break-glass escalation putting a human in the loop on blocked output.
AI Usage Control
Because every call passes through the chokepoint, the platform inherits visibility over which models and providers are actually being invoked.
FinOps for AI
Token budgets at organization or use-case scope, alert thresholds, hard-cap enforcement, cost estimation, and provider usage reconciliation.
Monitoring as Code
Governance configuration is versioned code — exportable as a portable JSON document and re-importable with validation.
AI Governance Platform
The seven-tab console: a central, organization-scoped view of live governance state across every use case.
Input Validation — Runtime Defense
Dangerous inputs are caught before the AI model ever sees them
Before any AI model is called, every user input passes through a detection layer that scans for attempts to manipulate the system. This includes attempts to override the AI's instructions, hijack its identity, extract its internal configuration, bypass safety controls, or inject hidden commands disguised as normal text.
The platform detects seven categories of manipulation — from straightforward instruction overrides to sophisticated multi-step attacks that try to slip past controls gradually. When a serious threat is detected, the AI model is never called at all. The attempt is blocked, a record is written to the audit log, and the user receives a governed response. The AI never sees the malicious input, so it cannot act on it.
Because these checks run in application code — not inside the AI's prompt — they cannot be talked around, reasoned past, or overridden by clever phrasing. The detection fires regardless of what the AI model would have done with the input.
Output Validation — Runtime Defense
Every AI response is scanned before it reaches the user
After the AI model generates a response, that response is scanned against two layers of rules before anyone sees it. A set of universal rules applies to every workspace across the platform — these catch leaked internal instructions, exposed system configurations, credentials that should never appear in output, and signs that the AI has been manipulated into breaking character.
On top of the universal rules, each workspace can define its own domain-specific controls. An organization operating in healthcare can block medical advice or prescribing language. A financial services workspace can enforce sanction-check compliance. A public-facing deployment can prevent outcome guarantees or diagnostic claims. These rules are configured per workspace and enforced automatically — the AI cannot produce output that violates them.
Depending on the severity, a flagged response is either blocked entirely, partially redacted (for example, replacing a leaked credential with a placeholder), or flagged as a warning for review. Every action — block, redact, or warn — is recorded in the audit log with the specific rule that triggered it.
The Governance Console — LLM Observability
Continuous assurance, not a periodic audit
Traditional AI oversight is a point-in-time exercise: an audit is commissioned, evidence is gathered by hand, a report lands months later describing a system that has since changed. The console replaces that with live state — every governed call observable the moment it happens.
A first-class, organization-scoped workspace that renders the live governance state for a company — and, for group roles, across every company in the instance. Seven tabs, bilingual (FR/EN), with a real-time usage meter.
The Overview tab is the meter: five headline tiles — Tokens, AI Calls, Flagged, Blocked, and Estimated Cost — above a token-budget progress bar that fills green / amber / red as usage approaches the budget, and a per-use-case table with tokens, budget %, status, and flagged/blocked counts.
Token usage vs budget, AI-call / flagged / blocked / est.-cost tiles, org budget bar, per-use-case table with status.
The coverage map — every AI capture point in the platform (input → model → output) with live call/token/flagged/blocked counts and last-seen timestamp.
The audit feed — recent governed interactions (timestamp, use case, persona, action, model, tokens, OK / flagged / blocked), with a flagged-only filter.
The access matrix — organization members and per-use-case membership, with add / invite / change-role / remove. Company admins and owners only.
Define and manage token budgets at organization or use-case scope: token limit, alert threshold %, and a hard-cap toggle (block vs warn).
Content-logging mode, availability behavior, config export/import, certified deletion, and provider reconciliation.
Cross-company consolidation — instance-wide usage, per-company rollup, group-role management, and per-company workspace entitlement grants.
Budgets & Metering — FinOps for AI
Financial accountability enforced at the same chokepoint as safety
Most governance tooling stops at safety and compliance, leaving cost to a separate FinOps product that reconciles invoices after the fact. Consumption control belongs in the governance layer — it is the same call, the same ledger, the same enforcement point.
Usage is never stored separately. It is aggregated from the period's audit-log rows — token estimate, call counts, flagged, and blocked — rolled up per use case and per organization. The meter cannot drift from what actually happened, because it is derived from the record of what actually happened.
Budget Scope
Set at organization or use-case scope, with a configurable period (monthly by default). Token budget, alert-threshold percentage (default 80%), and a hard-cap flag.
Enforcement
Only a hard-capped budget at or over its limit blocks (HTTP 429). Non-hard-cap budgets surface warning and over-budget status but do not stop the work — they alert, they don't block.
Cost Estimation
Tokens are converted to approximate cost using blended per-model rates, shown as "Est. cost" on the meter.
Provider Reconciliation
Pull the provider's own metered usage and cost for the current month (Anthropic and OpenAI wired) to reconcile against KriftAI's per-call estimate — closing any gap between estimate and billed reality.
Access Control — Least Privilege
Three layers of access governance, plus per-workspace tool gating
Access is governed at the organization, workspace, and group level. Tool access is default-deny — even if the model requests a tool, the platform blocks it unless the workspace is explicitly permitted. Agent capability is not a matter of what the model decides it can do; it is a matter of what the workspace has been granted.
Organization Roles
Owner · Admin · Member
Membership and administration of a single company — who can write budgets, settings, access, and run exports.
Workspace Members
Owner · Admin · Member · Viewer
Per-project membership shown in the access matrix — who can see and act in a given workspace.
Group Roles
Group Admin · Group Auditor
Cross-company scope: the auditor reads every company (no control); the admin controls across all companies. Separates scope from level.
Per-Persona Tool Gating — Default Deny
Each workspace type carries an allow/deny tool list, default-deny. Advisory workspaces deny command-execution and file-mutation tools. Developer workspaces allow build/run tools but deny destructive ones (drop-table, rm-rf). A tool is blocked even if the model requests it. Workspace types are gated per user and per company — group admins grant workspace entitlements from the Group tab.
Human Escalation — Human in the Loop
Break glass — not a workaround around governance, but part of it
When output is blocked, a human can request a reviewed override rather than silently losing the work. High-stakes actions route to a person by design, and the decision is itself on the record.
Request
A blocked result can be escalated with a documented reason. The request is stored pending, with the full violation detail and the blocked output preserved.
Review
An admin approves or denies the override. The decision writes its own audit row — override-approved or override-denied — with the escalation ID. The exception is itself on the record.
States
Pending → Approved / Denied / Expired. A pending-review queue lists outstanding requests oldest-first. Nothing falls through the cracks.
Configurable Policy — Monitoring as Code
Two policy dimensions per organization — both take effect immediately
Governance configuration is not a set of checkboxes in an admin panel that no one can reconstruct six months later. It is versioned, exportable as a portable JSON document, and re-importable with validation — governance treated as code, and governance that travels between instances.
Content-Logging Mode
How much content the audit log keeps — choose the tradeoff between traceability and privacy.
Interaction content stored as-is (truncated) in the audit summary. Default.
Content replaced with a SHA-256 fingerprint — verifiable for tamper-checking, not human-readable.
No content and no length persisted — only who, when, model, and verdict remain.
Availability Behavior
What happens if a governance check itself cannot run — the safety posture of the system.
If a validator throws, the call proceeds without that check — for non-critical scopes. Default.
If a validator throws, the call is blocked with a "governance unavailable" violation — for sensitive scopes like financial services.
Data Management & Compliance
Export, portability, and certified deletion
Config Export / Import
The organization's governance configuration — settings and budgets — exports as a portable, versioned JSON document and re-imports with validation. Governance travels between instances.
Audit-Trail Export
The full audit trail exports as JSON or CSV (fixed column order), optionally since a date, with a truncation header. Admins and owners only.
Certified Deletion — Right to Erasure
An organization owner can permanently delete the company's audit trail (optionally only rows older than a cutoff) and receives a tamper-evident deletion certificate — a SHA-256 digest over the org, requester, timestamp, row count, scope, and cutoff. Irreversible, confirmation required. The certificate proves the deletion happened, what was deleted, and when.
Database-Level Enforcement
Governance is not just application-layer — the database itself enforces it
Eight purpose-built tables form the persisted schema behind every governance control. Row-level security policies enforce tenant isolation at the database level — the database refuses cross-tenant reads regardless of application logic.
One row per governed model call — summaries, model/provider, token estimate, verdict flags, content-logging mode. Users see only their own rows via RLS.
Break-glass override requests — blocked output, violations, reason, status (pending/approved/denied/expired), reviewer and notes.
Budget and policy only (not consumption) — scope, token budget, alert-threshold %, hard-cap flag, period.
Per-organization policy — content-logging mode and availability policy.
Company RBAC — owner / admin / member per (organization, user).
Per-project membership — owner / admin / member / viewer.
Instance and group RBAC — group_admin / group_auditor.
Registers the governance console as a first-class, organization-scoped workspace.
FAQ
Frequently Asked Questions
What is AI governance at KriftAI?
AI governance at KriftAI is a code-level enforcement layer — not a policy document. Every AI call passes through a single governed chokepoint where input validation, output validation, and audit logging execute in code. A CI test fails the build if any file calls the raw model provider directly. Governance cannot be bypassed because it is the only call path.
How is this different from other AI governance platforms?
Most AI governance is prompt enforcement — rules written into the LLM's system prompt, hoping the model follows them. KriftAI uses code enforcement: validators are rule and regex engines that execute in application code and fire regardless of what the model does. The governance layer also operates at the database level with row-level security policies that enforce tenant isolation independent of application logic.
What happens when governance blocks a response?
A human can request a reviewed override — a break-glass escalation — with a documented reason. An admin approves or denies, and the decision itself is written to the immutable audit log with the escalation ID. The override is on the record, not a workaround around it. States: pending → approved / denied / expired.
Can governance configuration be exported and imported?
Yes. The organization's governance configuration — settings and budgets — exports as a portable, versioned JSON document and re-imports with validation. Audit trails export as JSON or CSV. Governance travels between instances.
How does KriftAI handle the right to erasure?
An organization owner can permanently delete the company's audit trail and receives a tamper-evident deletion certificate — a SHA-256 digest over the org, requester, timestamp, row count, scope, and cutoff. The certificate proves the deletion happened, what was deleted, and when. Irreversible, confirmation required.
Explore Each Control
Go deeper on any part of the layer
Each control has its own page — how it works, what it catches, and what happens when it fires.
Runtime Defense
Prompt Injection Defense
Seven threat types, detected in code before the model runs.
Runtime Defense
Output Validation
Universal and workspace rules — block, redact, or warn.
Observability
AI Audit Trail
Continuous assurance instead of a periodic audit.
FinOps for AI
AI Cost Control
Token budgets and hard caps at the same chokepoint as safety.
Agentic Security
Human in the Loop
Break-glass override, recorded rather than hidden.
Least Privilege
Access Control
Three role layers plus default-deny tool gating.
Framework Mappings
How these controls map to the frameworks you report against
Mappings, not certification claims — which controls produce evidence for which requirements, and what your organization still has to supply itself.
Articles & Insights
Perspectives on governing AI
Case Studies
Governance in action
How organizations deploy KriftAI's governance layer in real environments.
Case Study
Financial Services — Vancouver
How we eliminated 2 hours of morning spreadsheet work for a Vancouver financial services team.
Coming Soon
More case studies
Industry-specific governance deployments across regulated sectors.
Governance that cannot be bypassed because it is the only call path
See how KriftAI enforces AI governance at the code and database level — not as a prompt instruction, not as a policy document, but as runtime infrastructure.