Control what your AI agents are allowed to do.

The problem

The agent is not broken. It does what it is designed to do: read input and act on it. The trouble is that the input can carry instructions you never wrote, and the agent can reach tools and data that matter. Detection alone does not save you, because the attacker's tool is more capable than any detector you put in front of it. What saves you is structure: deciding, in advance and in one place, what the agent is allowed to do and actually tries to do, and being able to show exactly what happened.

What Swiftward does

• Tool and MCP permissions. Decide which tools an agent may call and with what parameters. Deny by default, allow on purpose. Agent permissions
• Stop sensitive data leaking into LLMs. PII, credentials, and proprietary source code, detected and redacted or rejected before a prompt ever leaves your environment. PII redaction is well understood; recognizing your own source code, so it cannot be pasted into ChatGPT, Cursor, or Claude Code, is the harder and rarer piece. Swiftward does both. Personal data and secrets · Code-leak prevention
• Keep your AI on-policy. Your support agent should not answer the questions it is not allowed to, break a rule that applies to you, or say something that discredits you. Swiftward checks what the AI says against your policy, with fast classifiers and an LLM-as-judge, and blocks, rewrites, or escalates what is off-policy. Keep your AI on-policy
• Prompt-injection defense, out of the box. A layered pipeline normalizes the input, matches known patterns, and runs an ML classifier, then blocks on a hard match or on model-and-gate consensus. Prompt injection
• Human-in-the-loop. Route the calls the engine flags to a reviewer. Their decision re-enters the same pipeline and lands in the same audit trail.

Use cases in depth

What it looks like in policy

Deny by default, allow on purpose: an agent reaches only the tools its role permits. Plain YAML, versioned and replayable.

signals:
  tool_allowed:
    udf: mcp/tool_allowed_for_roles
    params:
      tool: "{{ event.data.tool.name }}"
      roles: "{{ event.data.context.roles }}"
      role_permissions:
        support: ["crm_read", "ticket_*"]
        engineering: ["db_query", "github_*"]
        admin: ["*"]

rules:
  deny_unpermitted_tool:
    all:
      - path: "event.type"
        op: eq
        value: "tool_call"
      - path: "signals.tool_allowed"
        op: eq
        value: false
    effects:
      verdict: rejected
      priority: 100
      response:
        blocked: true
        reason: "Tool not permitted for this agent's role"

The same engine, your way to prove it

Every check above is a policy, not code buried in your application. You version it, test a change against real traffic in shadow mode before it affects anyone, roll back in one click, and replay any past decision on the exact version that was live. What you get: trace every decision, backtest new rules against past traffic, shadow-test against live traffic before you enforce.

Agents come in different shapes, from a single assistant to a fleet of sub-agents. The topology changes. The safety layer does not. Same rules, same enforcement, same audit trail.

Built for the security review

On-prem, SSO, layered access (role, row, and field level), secrets, and an append-only audit trail are built in, so the layer that governs your AI also passes the review your buyers and regulators run. Security · Enterprise foundation · Compare