Policy and Security

Control what agents can do, and mask what they can see

DataGrout enforces policy on every tool call. Semantic Guards validate requests before execution. Dynamic Redaction masks sensitive data after execution. Policies cascade from server defaults through integration overrides, and restrictions are monotonic – a child policy can tighten constraints but never loosen them.

Semantic Guards

Semantic Guards validate every tool call before it reaches the upstream integration. If a call violates policy, it is rejected with a clear explanation. No data leaves DataGrout until the guard passes.

Side Effect Controls

Restrict the maximum side effect level for a server or integration.

Set the level in your server’s policy settings. Any tool call that exceeds the configured level is blocked.

Destructive Operation Blocking

A separate toggle that blocks delete, drop, purge, and truncate operations regardless of the side effect level. Enable this as an additional safeguard even when write operations are allowed.

Scope Verification

Guards verify that a tool call targets only the integrations and data scopes available to the requesting agent. Calls that attempt to access integrations outside the server’s configured set are rejected.

Dynamic Redaction

After a tool executes, Dynamic Redaction scans the response and masks sensitive data before it reaches the agent. Redaction is applied server-side – the agent never sees the original values.

PII Auto-Detection

When PII controls are enabled, DataGrout automatically detects and masks:

• Email addresses
• Phone numbers
• Social Security numbers
• Credit card numbers
• Physical addresses
• Dates of birth

Redaction Strategies

You choose how each field type is masked.

Field-Level Rules

Define redaction rules per field name. For example, you can apply mask_email to all fields named email or PrimaryEmailAddr, and apron with 4 visible characters to fields named credit_card.

Cadence — Intelligent Loop Detection

MCP clients and autonomous agents can fire the same tool call multiple times — due to retries, network issues, or agent loops. Cadence goes beyond simple time-window deduplication by understanding the consequence of each tool call and detecting whether the world state changed between identical calls.

How It Works

Cadence operates on two layers:

Layer 1 — Consequence-Aware Session Tracking. Every tool call is hashed into an idempotency key (tool name + canonical JSON args) scoped to the MCP session. A monotonic state sequence counter increments on every tool completion. If the sequence hasn’t advanced between two identical calls, nothing in the session changed — it’s a loop. If another tool ran in between, it’s a legitimate pattern and the call proceeds.

Layer 2 — Time-Window Backstop. The traditional debounce mechanism remains as a secondary defense. Tool calls are hashed by server identity, tool name, and argument content. After execution, the outcome (success or error) is recorded. When an identical call arrives within the configured window, it is blocked immediately.

Consequence Tiers

Every tool is automatically classified by its declared side-effect metadata — no per-tool configuration needed:

Write-tier confirmation gates return isError: false with structured guidance so agents can adapt their behavior rather than interpreting the response as a failure.

Auditing

When a call is blocked by the time-window backstop, the debounce_attempts counter on the original execution record is incremented. Both layers include the original receipt_id in the response for traceability.

Configuration

• Cadence session tracking is always active — no configuration needed. Tiers are derived from existing tool metadata.
• Time-window backstop is configurable per server in the Interaction Settings tab:
  • Enabled by default with a success rule at 60 seconds.
  • Add multiple rules per response type (success/error), adjustable from 5 to 300 seconds each.
  • Can be disabled entirely for workflows that intentionally repeat identical calls.

Policy Cascade

Policies flow through a strict hierarchy:

User Account Settings
  └─ Server-Level Defaults
       └─ Integration-Level Overrides

At each level, you can tighten restrictions but never loosen them. If the server policy sets side effects to “Read”, an integration override cannot escalate to “Write”. It can only restrict further to “None”.

This means:

• A permissive server policy lets you customize per integration.
• A restrictive server policy locks down every integration beneath it.
• You never need to worry about an override accidentally opening a hole.

How to Configure

Server-Level Policies

1. Navigate to Settings and click the gear icon on your server.
2. Open the Policy section.
3. Set:
   • Side effect level (None / Read / Write / Delete)
   • Destructive operations toggle (on/off)
   • PII detection toggle (on/off)
   • Field redaction rules

These become the defaults for every integration on this server.

Integration-Level Overrides

1. Open an integration’s detail page.
2. Navigate to the Interaction Settings tab.
3. Toggle Override server defaults.
4. Configure tighter restrictions for this specific integration.

For example, your server might allow Write operations, but you restrict a particular integration to Read-only because it connects to a production database.

Examples

Read-Only Agent

Lock an entire server to read-only access:

• Side effects: None
• Destructive operations: Off

Every tool call that attempts to create, update, or delete data is blocked.

PII-Safe Reporting

Allow data access but mask personal information:

• Side effects: Read
• PII detection: On
• Email fields: mask_email
• Phone fields: mask_phone
• SSN fields: mask_all

Agents can query data freely. All personally identifiable information is masked before it reaches the agent.

Mixed Policy

Allow writes to your CRM but restrict billing to read-only:

• Server default: Write
• CRM integration: inherits Write (no override)
• Billing integration: override to Read

Schema Compatibility

DataGrout automatically sanitizes tool schemas for cross-platform compatibility. When tools from external MCP servers use advanced JSON Schema keywords, these can cause errors on LLM APIs that only support a subset of the specification.

Unsupported Keyword Stripping

Keywords like exclusiveMinimum, exclusiveMaximum, const, $comment, deprecated, readOnly, and others are automatically removed from tool schemas before they are served to clients. This prevents errors from APIs (such as Gemini) that reject these keywords.

Structural Fixes

• Type arrays ("type": ["string", "object"]) are simplified to accept any type
• oneOf/anyOf blocks are flattened into merged properties
• Array schemas missing items get a default items added

Tool Name Deduplication

When using OpenAI-compatible tool names, names are truncated to 64 characters. If two tools produce the same name after truncation, DataGrout appends a numeric suffix (_2, _3, etc.) to ensure uniqueness, preventing “duplicate tool name” errors from clients.

Composite Billing

When a tool call uses gateway parameters like refract or chart, multiple credits charges occur independently:

• Gateway base (1 credit) — charged for every tool call
• Refraction (10 credits new / 1 credit reuse) — charged by prism.refract
• Chart (10 credits new / 1 credit reuse) — charged by prism.chart
• CTC minting (10 credits) — charged when a Cognitive Trust Certificate is produced

Each tool charges its own credits and issues its own receipt. The gateway collects all inner receipts and presents a composite receipt in the response metadata with a per-component breakdown:

{
  "composite": true,
  "total_charged": 21,
  "total_estimated": 21,
  "total_savings": 0,
  "components": [
    {"source": "gateway", "charged": 1, "estimated": 1},
    {"source": "prism.refract", "charged": 10, "estimated": 10, "savings": 0},
    {"source": "prism.chart", "charged": 10, "estimated": 10, "savings": 0}
  ]
}

On skill reuse, the savings are visible per-component:

{
  "source": "prism.refract",
  "charged": 1,
  "estimated": 10,
  "savings": 9
}

Tool prices are defined in a centralized pricing map (DataGrout.Pricing) designed for future migration to a database-backed admin panel.

Cryptographic Signing (DG CA)

DataGrout operates its own Certificate Authority (DG CA) that provides two signing layers:

Ed25519 Signatures

All trust artifacts produced by DataGrout are signed with Ed25519 using a platform-wide signing keypair. Signed artifacts include:

• Cognitive Trust Certificates — every CTC is signed over its immutable fields (id, plan hash, assurances, timestamp, and child certificate IDs). Including child CTC IDs in the parent signature makes certificate chains tamper-evident — altering or inserting a sub-certificate invalidates the parent.
• Rule packs — governance policy bundles distributed by the Arbiter are signed before deployment. Nodes verify the signature before applying policy changes.
• Machine-client JWTs — authentication tokens issued to automated clients (Conduit SDK, Substrate) are Ed25519-signed JWTs.

In production, the Ed25519 private key is injected via environment and never written to disk. In development, an unsigned fallback (SHA-256 digest) is used so the system runs without secrets.

ECDSA P-256 (X.509 Identity)

A separate ECDSA P-256 key is used exclusively for X.509 certificate signing. Substrate clients generate a key pair locally and send their public key to the DG CA, which returns a signed client certificate for mutual TLS. In production, the P-256 private key lives inside an AWS KMS HSM (FIPS 140-2 Level 2) and never leaves the hardware boundary.

Signature Verification

CTC signatures can be verified by anyone with the DG CA public key, which is served at GET /ca.pem. The CTC viewer displays verification status for each certificate, and the public key is embedded in the Conduit SDK for offline verification.

Certificate Chains

When multiple inner tools produce Cognitive Trust Certificates, the gateway collects them into a certificate chain. Each CTC is independently signed with Ed25519 and verifiable. The chain appears in _meta.datagrout:

• ctc — the primary certificate (typically from refraction)
• certificate_chain — all certificates in order, each with id, viewer_url, assurances, and guarantees

Because each parent CTC’s signature covers its child certificate IDs, the chain is tamper-evident end-to-end. Modifying any certificate in the chain invalidates every ancestor’s signature.

Chart rendering now produces its own CTC with deterministic assurances (same input always produces the same SVG output, sandboxed, no side effects).

The chain can be toggled via the Include CTC details checkbox in Interaction Settings.

Related

• Interaction Settings – Full configuration reference
• Cognitive Trust Certificates – Policy compliance verification in workflows
• Core Concepts: Policies – Policy overview