Dynomo hubDynomo
Data Governance & AI

Every data boundary, governed.
Every AI request, protected.

Dynomo's Policy Engine classifies every field in your data structures, evaluates rules automatically at every execution boundary, and ensures protected data never reaches an external AI, API, or log โ€” whether the workflow runs correctly or fails.

๐Ÿ‡ช๐Ÿ‡บEU data residency
โš–๏ธGDPR + NIS2 built in
๐Ÿ”’Fail-closed at every boundary
๐Ÿค–MCP for any AI model

Why governance cannot be optional

Data leaves through the boundaries teams rarely see.

Workflows do more than move data between systems. They expose it to logs, previews, external APIs, and AI models. If protection depends on someone remembering to add a step, the control is already too late.

Unprotected paths01

Data governance is bolted on, not built in

Most platforms treat governance as an afterthought โ€” a configuration step, a custom node, or a separate product. The result: sensitive data leaks into logs, AI prompts, and third-party APIs because a developer forgot to add the redaction node.

External AI boundary02

AI introduces a new category of data exposure

When a workflow sends data to an external AI model, every personal, financial, and identity field in that payload leaves your controlled environment. Most integration platforms have no answer for this. They expose the raw payload.

Missing evidence03

Compliance teams cannot audit what they cannot see

Without versioned, assigned policies and an evaluation audit trail, a compliance audit requires digging through workflow configuration files and hoping nothing changed since the last review. That is not governance โ€” it is archaeology.

The policy engine

Classify once. Enforce everywhere.

Each field is classified by what it contains and how sensitive it is. Dynomo resolves the applicable policy for the current boundary, then allows, masks, tokenizes, omits, or blocks the field before data moves.

01
Classify the fieldCategory + sensitivity
02
Resolve the policySystem through node
03
Enforce the actionAt the execution boundary

Cached policy evaluation runs in process โ€” no synchronous policy call for every field.

Policy inheritance

Control becomes stricter toward execution

01
System

Mandatory guardrails

The platform baseline cannot be weakened by any workspace.

02
Workspace

Reusable operating policy

Versioned rules can be assigned across the targets a team owns.

03
Execution

Connector โ†’ workflow โ†’ node

Local overrides can add protection, but are stricter-only by default.

04
Resolved

One effective policy

The full hierarchy and winning rule remain visible in the UI.

Policy rule exampleAI_EXTERNAL context
When category is secret
BLOCK
When category is identity + sensitivity โ‰ฅ high
TOKENIZE
When category is personal + sensitivity moderate
TOKENIZE
When category is financial + sensitivity high
OMIT
When category is contact
MASK
When sensitivity is restricted
BLOCK
When default
ALLOW

Rules are matched top-down. BLOCK and OMIT are terminal โ€” they short-circuit remaining evaluation for that field.

AI & MCP

Connect any AI model. Your data stays yours.

Dynomo exposes a single MCP interface that connects to any AI engine โ€” OpenAI, Claude, Gemini, Mistral, or your own self-hosted model. Before every request, the policy engine runs. After every response, tokens are restored inside your environment.

Raw dataPolicy boundaryProtected data
Step 01

Workflow data

Raw input
firstNameMarie
emailm@corp.eu
revenue480,000
Step 02

Policy evaluation

Protected boundary
personalTOKENIZE
financialOMIT
restrictedBLOCK
Step 03

Sanitised AI request

Safe to send
firstNameTKN_01J8A
emailTKN_01J8B
revenueOMITTED
Step 04

AI model response

Tokens only
subjectTKN_01J8A
resultAnalysis ready
identityNot exposed
Step 05

Token restoration

Inside Dynomo
TKN_01J8AMarie
TKN_01J8Bm@corp.eu
token mapExpires
Step 06

Workflow continues

Governed output
contextRestored
auditRecorded
values storedNone

Any AI model

OpenAI, Anthropic Claude, Google Gemini, Mistral, or your own self-hosted model. Dynomo connects through a single MCP interface.

Tokenization before every AI request

Personal and contact data is replaced with opaque tokens before the AI sees the prompt. The AI operates on tokens, not real identities.

Block restricted data at the boundary

Secret, restricted-sensitivity, and health data doesn't reach the AI at all. The request is stopped if those fields can't be safely omitted.

Exact token restoration inside Dynomo

When the AI returns a response containing tokens, Dynomo substitutes back the originals inside your secure environment. The AI never sees the restoration.

Run-scoped, expiring token maps

Token-to-value maps are encrypted, scoped to the specific workflow run, and expire automatically. Tokens cannot be restored in a different run or workspace.

Full audit trail, no values stored

Every AI request records context, policy version, token counts, and blocked fields. Original values are never written to audit storage.

Context-aware actions

The destination changes the protection.

A contact field may be allowed in an approved internal API, tokenized before an AI request, and masked in a log. Dynomo evaluates the field, sensitivity, and execution boundary together every time data moves.

ALLOWValue passes through unchanged.
MASKRetain partial representation โ€” e.g. j***@example.com
REDACTReplace with [REDACTED]. Type-compatible.
TOKENIZEReplace with opaque token. Reversible only inside Dynomo.
HASHIrreversible keyed digest via HMAC. Consistent across runs.
OMITRemove the property entirely from the payload.
BLOCKStop the operation before it crosses the boundary.
Example baseline policy

One classification, four execution contexts

Resolved automatically at runtime

Data categorySensitivityExternal AIExternal APILogsPreview
secretrestrictedBLOCKBLOCKBLOCKBLOCK
identityhighTOKENIZEOMITREDACTREDACT
personalmoderateTOKENIZEMASKMASKMASK
financialhighOMITOMITREDACTREDACT
contactmoderateMASKALLOWMASKMASK
healthrestrictedBLOCKBLOCKBLOCKBLOCK
nonelowALLOWALLOWALLOWALLOW
Data category

secret

restricted
External AIBLOCK
External APIBLOCK
LogsBLOCK
PreviewBLOCK
Data category

identity

high
External AITOKENIZE
External APIOMIT
LogsREDACT
PreviewREDACT
Data category

personal

moderate
External AITOKENIZE
External APIMASK
LogsMASK
PreviewMASK
Data category

financial

high
External AIOMIT
External APIOMIT
LogsREDACT
PreviewREDACT
Data category

contact

moderate
External AIMASK
External APIALLOW
LogsMASK
PreviewMASK
Data category

health

restricted
External AIBLOCK
External APIBLOCK
LogsBLOCK
PreviewBLOCK
Data category

none

low
External AIALLOW
External APIALLOW
LogsALLOW
PreviewALLOW

Governance that runs at platform depth.

Not a configuration step. Not a node you remember to add. A system that evaluates at every boundary and fails closed when it can't.

Policy-as-rules, not configuration

Write governance rules once and assign them anywhere โ€” to a workspace, a connector, a specific workflow, or a single node. Rules are versioned, immutable once published, and reusable across your entire stack.

Enforcement at every boundary

Policies aren't optional nodes in a workflow. They enforce automatically before external API calls, AI prompts, connector writes, log persistence, and preview rendering. There's no path around them.

Fail-closed at external boundaries

When a policy is unavailable or evaluation fails at an external AI or API boundary, Dynomo stops the operation. Protected values never leave in degraded mode. Logs get an emergency redactor instead of silence.

Versioned policy lifecycle

Policies move through Draft โ†’ Published โ†’ Archived. Published versions are immutable โ€” a new draft is required to change them. Audit records capture exact version IDs, so you can always explain which rule made which decision.

Effective policy resolution

Policies stack: System โ†’ Workspace โ†’ Connector โ†’ Workflow โ†’ Node. Mandatory system guardrails cannot be weakened at lower scopes. See the full resolved hierarchy and the winning rule for any field, in any context.

Audit that never stores protected values

Every evaluation records context, policy version IDs, action counts by category, and blocked/degraded state. Original protected values, restored tokens, and connector credentials are never written to audit storage.

๐Ÿ‡ช๐Ÿ‡บ
EU only

All data processed in Amsterdam. Never leaves the EU.

โš–๏ธ
GDPR

Compliant by design. Right-to-erasure automated across connected systems.

๐Ÿ›ก๏ธ
NIS2

Network and information security requirements met at platform level.

๐Ÿ”’
Zero log leakage

Protected values never appear in logs, previews, errors, or audit records.

See the policy engine in context

Ready to govern your data at platform depth?

Book a governance session and we'll demonstrate the policy engine against your own data structures โ€” including AI tokenization on a live workflow.