Show HN: Runtime security enforcement and capability scoping for agents
Clay Seal provides runtime security for AI agents by checking each action as it happens, preventing misuse even if an agent is compromised. It offers three independent components: runtime authority (capabilities), attested identity, and verifiable receipts.
Now onboarding design partners
Agent actions sealed at runtime.
Most systems hand an AI agent a broad set of permissions at the start and trust it for the rest of the session. Clay Seal checks each action as it happens and keeps a record of it. If the agent starts doing something it shouldn't, its next action is blocked.
Use one layer, or the full stack. Read the docs or see how it works.
You're on the list.
We review applications weekly, and you'll hear from a person. In the meantime, the docs are open.
Why now
Why static permissions fall short
An API key or OAuth scope gives an agent the same access for the whole session, no matter what it does with it. That's fine for regular software. But an agent can be talked into misusing that access partway through a task, and by then it already has everything it needs.
capabilities
Approve each action
Before an agent does anything it can't undo, it has to present a token that was issued for that specific action. If the details have changed or the token has already been used, the action is blocked.
identity
Know who's acting
Each action is linked to the program that ran it and the person who owns it. That link comes from where the code is actually running, so a stolen key on its own doesn't get anyone in.
receipts
Keep a record you can check
Everything an agent does, and everything it's blocked from doing, is saved as a signed record. You can give that record to an auditor or a customer and they can verify it themselves.
The stack
Three parts, and each one works on its own
Most teams start with whichever part solves their most urgent problem and add the others later.
clayseal-capabilities
Runtime authority
Instead of approving a whole session at once, Clay Seal approves the next single action an agent wants to take. The token it gets only works once, and it stops working if any of the details change.
Commit tokens and the sandbox governor in the docs →
capabilities
ok, reason = verify_commit_token(token, ctx=ctx)
mutated arguments? ✗ arguments_hash mismatch
second presentation? ✗ already used (replay)
unknown signer? ✗ untrusted minting key
revoked mid-task? ✗ permit epoch stale
exactly as granted: ✓ proceed
clayseal-identity
Attested identity
An agent has to prove where it's running before it gets any credentials. Those credentials are short-lived and tied to a key only that agent holds, so a stolen token on its own is useless.
How attestation works →
identity
agent = auth.identify( agent_type="researcher", owner="[email protected]", scopes=["db:read", "web:*"], ttl_seconds=3600, ) agent.spiffe_id
spiffe://acme.ai/customer/acme/agent/researcher
clayseal-receipts
Verifiable receipts
Every action is saved as a signed record that includes the policy it ran under. The records are linked together, so if someone edits one later, it's easy to catch.
The verification model →
terminal
$ arctl verify-bundle receipts/cs_9f2c.json signature ed25519 ✓ trusted signer audit chain inclusion proof ✓ (n=1,204) policy refunds.yaml v3 satisfied ✓ tamper check 0 mutations survive VERIFIED offline in 412ms
How it works
What happens on each action
Attest
The agent proves where it's running and gets an identity to act under.
Scope
Your policy becomes a specific list of what it's allowed to do.
Steer
Each action is checked as it happens, and a run that goes wrong gets stopped.
Seal
The result is saved as a record you can check later.
Our seal of approval.
Why “Clay Seal”
It's an old idea
A long time ago, people sealed shipments with a stamp pressed into clay. If the clay arrived unbroken and the stamp matched, you knew who sent it and that no one had opened it on the way, without having to trust the courier who carried it.
Clay Seal does the same thing for the work agents do. It records each action as it happens, so anyone can check it afterward.
Built on open standards, so anyone can check a receipt without trusting us.
SPIFFE / SVID
Biscuit tokens
Ed25519
RFC 6962 Merkle proofs
SCITT
C2SP tlog-tiles
OIDC
MCP
AWS Nitro attestation
OpenTelemetry GenAI
Get your agents on the record.
Tell us what your agents do and we'll show you how Clay Seal would fit.
Join the waitlist