Now onboarding design partners

Agents change mid-task. Their permissions should too.

pip install clayseal-identity

Clay Seal sandboxes agents at runtime. Each action is checked against what the task needs now, not what the agent received at launch.

A sandbox that moves with the task.

The permissions an agent starts with are a guess about everything it might ever need. Clay Seal keeps a live sandbox around the agent instead. The walls move in as the task takes shape, and anything that reaches outside them is blocked, no matter what the original grant allowed.

One task, replayed.

A support agent refunds an order with Clay Seal in the loop.

  1. The agent reads order 8841. Allowed and sealed. Scope narrows to this order.
  2. It refunds 49 dollars through Stripe. Allowed and sealed.
  3. It emails the customer on the order. Allowed and sealed.
  4. It tries a bulk customer export. Blocked outside the trajectory. No seal.
  5. A signed receipt records all four decisions, verifiable offline.

Delegation narrows.

When an orchestrator spawns subagents, every hand-off attenuates: a child holds only part of its parent's sandbox. Each delegation is sealed like any other action. Compromise a subagent and you've reached a sliver, not the estate.

How the seal gets made.

  1. step 1: attest

    Attest

    The agent gets a short-lived identity bound to its own key. No standing API keys to leak, nothing to rotate.

  2. step 2: scope per action

    Scope per action

    Each tool call is authorized against the trajectory so far. What the agent just did decides what it can do next.

  3. step 3: seal

    Seal

    Every decision emits a signed receipt. Verify it offline without calling Clay Seal.

Receipts, not promises.

Every decision leaves a receipt you can verify without us. If Clay Seal disappears tomorrow, your audit trail still checks out.

verifies offline. no vendor call.

clay seal · action receipt
action
Refund via Stripe
scope
order #8841 · up to $49.00
decision
Allowed. sealed ✓
identity
support-bot@acme · attested · 300s TTL
signature
ed25519 9f2c…b417

The identity layer is open source.

pip install clayseal-identity

GitHub · PyPI · Docs

Questions.

What is Clay Seal?

Clay Seal is a runtime security layer for AI agents. Instead of trusting the permissions an agent received before a task started, Clay Seal keeps a live sandbox around the agent while it runs. Tool calls are checked against the current task. Allowed actions leave signed receipts, and out-of-scope actions are blocked.

How is a dynamic sandbox different from static permissions or OAuth scopes?

A static grant is a guess made before the task starts. It stays live for the whole session. Clay Seal's sandbox narrows as the task takes shape, so the standing attack surface gets smaller instead of staying wide open.

What is an action receipt?

Every authorization decision emits a signed receipt recording what happened and which agent did it. Receipts verify offline with the open-source tooling, so your audit trail does not depend on Clay Seal being online.

Does Clay Seal work for multi-agent systems?

Yes. When an orchestrator spawns subagents, each hand-off gives the child only part of the parent's sandbox. Compromising one subagent exposes a sliver of scope, not the whole estate.

Is Clay Seal open source?

The identity layer is open source and on PyPI: pip install clayseal-identity. It gives agents short-lived credentials and capability tokens. The source lives on GitHub.

Who should use Clay Seal?

Teams running AI agents against real systems like payment flows and source control. Clay Seal helps them reduce standing access and keep a verifiable audit trail. We're currently onboarding design partners.

Seal your first agent this week.

We're onboarding a small set of design partners running agents against real systems like payment flows and source control. The open-source layer is yours either way.