Skip to main content

product

From unknown agents and flows to provable control, in six steps.

Discovery, classification, identity, policies, gateway, audit. Each Kimetai capability answers one of the questions your auditor — or your regulator — will ask about every automation running in your company.

  1. 01 discovery
  2. 02 classification
  3. 03 identity
  4. 04 policies
  5. 05 gateway
  6. 06 audit
01 · DISCOVERY

Find every automation. Including the ones you don’t know about.

answers: “What are you?”

Connectors to OpenAI, Anthropic, n8n, Make, Zapier, Salesforce, Zoho, Microsoft and 20+ platforms, so you hold a live inventory of both species of automation in your company: AI agents and deterministic workflows, integrated into Kimetai with no installation on your side. The first connection usually surfaces more operating automations than the CTO expected.

  • Detection of stale or hidden automations across your no-code and orchestration platforms
  • Self-diagnosis of dependencies: agents, workflows, AI models, triggers and actions on connected apps
  • Alerts on new automations and behavioural drift
  • Diagnostic support: risk surface per automation, one applicable regulation at a time

the inventory itself is the deliverable · GDPR art. 30 · NIS2 art. 21.2.i · DORA art. 8

discovery_scancomplete
Automations found per connected platform
PlatformAutomations foundUndeclared
n8n34 workflows6 shadow
Salesforce13 workflows · 8 agentsUndeclared: none
OpenAI18 agents3 shadow
Make12 workflows2 shadow
Zapier9 workflowsUndeclared: none
94 automations inventoried · 68 workflows · 26 agents11 shadow flagged

Illustrative view · synthetic data

02 · CLASSIFICATION

An inventory without classification is just a list.

answers: “Which rules reach it?”

For every automation Kimetai assigns an owner, the data classes it reads, the systems it writes into, its business criticality and the frameworks that reach it. The classification is versioned and reviewed again the day the flow changes — the day someone adds an AI step to a deterministic workflow, its regime moves, and only a live census notices.

  • Named owner per automation, so nothing runs unassigned
  • Proposed risk level and applicable frameworks, ready for your review
  • Re-classification triggered by change, not by calendar

the field an auditor opens first · GDPR art. 30 · NIS2 art. 21.2.i · AI Act Annex III

classification_recordv2 · reviewed 12 days ago
AUTOMATION
flow://n8n/invoice-replication
OWNER
Head of Finance
CRITICALITY
High
DATA CLASSES
Personal · financial
WRITES INTO
Sage · Stripe
APPLICABLE FRAMEWORKS
  • GDPR art. 30 · 32
  • NIS2 art. 21.2.i
  • VeriFactu · 2027
  • AI Act · not applicable

Illustrative view · synthetic data

03 · IDENTITY

A cryptographic identity for every agent — and a human behind it.

answers: “Who backs you?”

Each agent gets a W3C DID and a signed verifiable credential any external system can check without trusting the agent itself. Every credential names the accountable human — the traceability the AI Act and the Product Liability Directive demand.

  • W3C DIDs + Verifiable Credentials, standard crypto
  • Federation with Okta, Entra ID, Google Workspace
  • Automatic key rotation, global revocation in seconds

no more permanent embedded credentials · GDPR art. 32 · NIS2 access control

verifiable_credential
did:
did:kimetai:acme:7f3a…c2e1
issued:
2026-06-14 · Ed25519
backed_by:
Head of Payables
scope:
finance.payables · read+authorize
status:
activerevocation: global, <5s

Illustrative view · synthetic data

04 · POLICIES

Policy as code. Versioned, reviewable, simulated before it ships.

answers: “What can you do?”

Declarative policies — OPA syntax extended with agent primitives — evaluated in-line on every call. Scope by agent, action, amount, destination, time window or data class. Simulate any new policy against your last 30 days of traffic before enforcing it.

  • Hierarchical inheritance: org → department → agent
  • Human approval steps for sensitive actions
  • Temporary delegation with auto-expiry
  • Three ways to write a policy: code, if…then blocks or the AI assistant

preventive controls, not detective ones · GDPR art. 22.3 · AI Act art. 14

policies/finance.regov3 · reviewed
package kimetai.finance

default allow = false

allow {
  input.action == "payment.create"
  input.amount_eur <= 5000
  input.vendor in data.approved_vendors
}

review {
  input.amount_eur > 5000
}

Illustrative view · synthetic data

05 · GATEWAY

The decision point in front of every consequential action.

answers: “Under which policy?”

Kimetai is an authorization point, not a payment processor: agents execute on their own rails with their own credentials, and Kimetai reconciles the outcome. Money never touches our accounts — a deliberate posture that keeps you and us outside the PSD2 perimeter.

  • Delegated budgets per agent, category and period
  • Anomaly detection: loops, duplicates, compromised agents
  • Multi-signature above configurable thresholds

keeps the invoicing chain intact · RRSIF art. 8 (VeriFactu) · structured e-invoicing

authorization_flow

  1. Agent requests authorization

    POST /v1/authorize · payment.create · €4,120

  2. Policy evaluated pre-execution

    ALLOW · signed Ed25519 · TTL 60s

  3. Agent executes on its own rail

    Stripe · SEPA · SaaS API — your credentials, never ours

  4. Webhook reconciles the result

    budget updated · event sealed in audit ledger

Illustrative view · synthetic data

06 · AUDIT

An audit trail that holds up in front of a regulator.

answers: “Can it be verified?”

Every event is hash-chained to the previous one and sealed with eIDAS-qualified timestamps. Reconstruct any decision chain — prompt, context, data touched, policy applied, human approvals — and export the evidence pack each framework asks for in minutes, not weeks: the AI Act technical dossier, the Art. 30 record of processing activities, the ICT asset register DORA and NIS2 expect, and the invoicing event log required under VeriFactu.

  • Tamper-evident hash chain, independently verifiable
  • Sub-second search across 10M+ events
  • One trail for every platform: no chasing n8n, Anthropic or Salesforce log by log, each with its own retention window
  • Export to Splunk, Datadog, Elastic — and to your regulator

one seal, four duties · GDPR art. 33 (72h) · NIS2 art. 23 (24h) · RRSIF art. 8 · AI Act art. 11

audit_ledgereIDAS sealed
  1. #48213 · payment.createn8nsealed
    prev 9f2c41…8ab0 → self 4b7de3…11f9
  2. #48212 · data.export.deniedAnthropicsealed
    prev c07a92…33d1 → self 9f2c41…8ab0
  3. #48211 · approval.humanSalesforcesealed
    prev 5518fe…0c44 → self c07a92…33d1 · ts eIDAS
  4. #48210 · record.replicatedMakesealed
    prev 2a91cd…77b5 → self 5518fe…0c44
  5. #48209 · ticket.classifiedOpenAIsealed
    prev 8fd304…19ac → self 2a91cd…77b5

Illustrative view · one chain, five platforms, one retention policy

the_difference

Observability tells you what went wrong. Enforcement stops it.

Monitoring stacks watch agents and automations. Kimetai sits in the execution path and decides.

WITHOUT A DECISION POINT

triggeractionlog

WITH KIMETAI IN THE PATH

triggerkimetai.authorizeaction

ALLOWREVIEWBLOCKone node in your flow · the action waits for the verdict

The difference shows up in four places:

  • WHEN IT ACTS

    MONITORING TOOLSAfter execution — the log is the first you hear of it.

    WITH KIMETAIBefore execution — no verdict, no action.

  • WHAT YOU GET

    MONITORING TOOLSDashboards and alerts to triage.

    WITH KIMETAIA signed allow / review / block decision, every call.

  • THE RUNAWAY AGENT

    MONITORING TOOLS127 duplicate purchase orders, found the next morning.

    WITH KIMETAIStopped at the third duplicate, human notified.

  • THE REGULATOR

    MONITORING TOOLSReconstructed narrative, best effort.

    WITH KIMETAISealed evidence: policy, verdict, approver, timestamp.

See it running on your own agents.

A 45-minute demo with your platforms — n8n, Salesforce, OpenAI or whatever your agents run on.

Book a demoSecurity & residency