Back to home
Runtime safetyGateway available now · SDK alpha

Every call passes policy before it executes.

Drop the Krynix MCP gateway in front of your agent and every tool call runs through policy first — with zero code changes. PII gets redacted before it leaves. Forbidden tools are denied at the call site. External network egress is gated by allowlist. Bad tool arguments never reach the dispatcher. One YAML file, four enforcement patterns.

The pain

Every prompt and every tool call is a runtime trust boundary.

Your support agent reads a ticket containing a customers SSN and ships it to OpenAI. Your DPO wakes up to a GDPR Slack thread.

Your coding agent decides rm -rf node_modules is a reasonable fix for a flaky test and runs it against the prod build server.

Your billing agent emails an invoice to [email protected]. The agent followed instructions. The instructions were from a prompt injection.

Your refund tool takes an amount. The agent thinks $25,000 is fine because nothing in the code says otherwise.

What Krynix does

One YAML. Four patterns. Drop in the gateway.

Point your MCP agent at the Krynix gateway instead of your tool server — one command, no code changes — and every tool call passes through the policy layer before it reaches the tool. (In-process SDK adapters for OpenAI, Anthropic, and LangChain are in alpha.)

Policies are YAML. Seven match operators. Four actions: allow, deny, redact, require-approval. Scope by agent, by tool, by event type. The agent code does not change — only the SDK initialization is wrapped.

Below are the four runtime patterns most teams need on day one. All of them compose; one policy file can contain all four.

The four day-one patterns

Pick whichever ones bite first.

PII redaction in prompts

redact

Pattern-match on field name or value. Replace with a typed placeholder. The model sees {{ssn}} instead of 123-45-6789, gives a coherent response, and the governance log records exactly which fields were redacted.

- id: redact-ssn
  match:
    event_type: llm_request
    payload:
      - field: prompt
        operator: regex
        value: '\\b\\d{3}-\\d{2}-\\d{4}\\b'
  action: redact
  replacement: "{{ssn}}"
  severity: high

Forbidden tool calls

deny

Some tools should never be callable by an agent, even if the agent thinks otherwise. Shell, exec, system, raw SQL — deny by name pattern. The agent gets a structured error explaining why.

- id: block-shell
  match:
    event_type: tool_call
    payload:
      - field: tool_name
        operator: matches
        value: "^(shell|bash|exec|system).*"
  action: deny
  severity: critical
  message: "Shell tools are not callable by agents"

External network egress

deny

When the agent has an HTTP tool, restrict targets to a domain allowlist. Catches prompt-injection-driven exfiltration before the request leaves your network.

- id: allowlist-domains
  match:
    event_type: tool_call
    payload:
      - field: tool_name
        operator: equals
        value: "http_request"
      - field: tool_args.url
        operator: not_matches
        value: "^https://(api|app)\\.yourcorp\\.com/"
  action: deny
  severity: high
  message: "HTTP egress restricted to yourcorp.com subdomains"

Tool argument bounds

require-approval

Numeric and enum bounds on the arguments your agent passes to high-impact tools. Refunds over a threshold, wire transfers over a limit, deletes of resources older than N days — all route to a human.

- id: refund-threshold
  match:
    event_type: tool_call
    payload:
      - field: tool_name
        operator: equals
        value: "issue_refund"
      - field: tool_args.amount_usd
        operator: greater_than
        value: 500
  action: require-approval
  approvers: ["support-leads"]
  message: "Refund over $500 requires team lead approval"

Want to try Krynix on your stack?

Request early access