◆ The authorization gate for AI agents

AI agents now act on your systems.
Nothing runs without your rule.

ZIFFER checks each action against your policy and signs the decision. Your code runs it with your own credential. The agent holds none, and ZIFFER never holds yours.

Scan your project, free →Book a 30-min sign-off review
npx @ziffer-io/scan --code --report
01Propose. Every action starts as a proposal. The agent holds no credential.02Grant. Your policy grants each action, holds it for your approvers, or refuses it.03Execute. Your code verifies the receipt, then runs the action with your own credential.04Prove. Every action that ran has a signed receipt. A third party can check the record.05Distribute. You sign your rules with your own key. ZIFFER cannot rewrite them.

◆ The authorization gate for AI agents

AI agents now act on your systems. Nothing runs without your rule.

ZIFFER checks each action against your policy and signs the decision. Your code runs it with your own credential. The agent holds none, and ZIFFER never holds yours.

Scan your project, free →Book a 30-min sign-off review
npx @ziffer-io/scan --code --report
01Propose. Every action starts as a proposal. The agent holds no credential.02Grant. Your policy grants each action, holds it for your approvers, or refuses it.03Execute. Your code verifies the receipt, then runs the action with your own credential.04Prove. Every action that ran has a signed receipt. A third party can check the record.05Distribute. You sign your rules with your own key. ZIFFER cannot rewrite them.

◆ In 67 seconds

Watch three actions meet one policy.

A routine change gets a receipt. An injected €48,000 wire waits for your approvers. An action with no rule is refused.

◆ In 67 seconds

Watch three actions meet one policy.

A routine change gets a receipt. An injected €48,000 wire waits for your approvers. An action with no rule is refused.

◆ Start in one command

Scan the repository where your agent’s tools are built, or give your AI assistant ZIFFER’s tools.

Finds the tools your code gives an AI model, and the ones that cannot be undone. It writes a report. You need no account, and nothing is sent anywhere.

npx @ziffer-io/scan --code --report

Read the documentationSource on GitHub

◆ Start in one command

Scan the repository where your agent’s tools are built, or give your AI assistant ZIFFER’s tools.

Scan your project

Finds the tools your code gives an AI model, and the ones that cannot be undone. It writes a report. You need no account, and nothing is sent anywhere.

npx @ziffer-io/scan --code --report

Claude Code

Adds the ZIFFER plugin and its six skills. They scan your code, put ZIFFER in it, build the policy, set up its pipeline and check the result. The plugin starts the MCP server itself.

claude plugin marketplace add ziffer-hq/ziffer-sdk
claude plugin install ziffer@ziffer

Other AI assistants

Put this command in your AI assistant’s MCP settings. It gives the assistant ZIFFER’s tools: scan your code, integrate the SDK, check your policy and try a decision.

npx -y @ziffer-io/mcp

Read the documentationSource on GitHub

Assume the injection works. Here are three ways it reaches your agent.

Your agents read email, tickets and documents you don’t control. A sentence in them becomes an instruction.

Your policy decides, whatever the model believed. An injected agent, a mistaken one and a misused one meet the same rule.

via an email it summarizesHidden text in the message tells the agent to forward what it can reach. The data leaves your tenant. Refused: no rule grants that action.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent holds the credential. Held: this policy’s 2-of-2 quorum, not met.
via a document it fetchesA fetched page moves a payment to a new payee. Nothing records who authorized it, because nobody did. Held until the approvers this policy names have signed.

Anyone who can put text in front of an agent can act with its credentials: an email, a ticket, a PDF, a web page. Tool descriptions are the fastest-growing channel. OWASP LLM01:2025: no fool-proof prevention of prompt injection is known. UK NCSC, 2025-12-10: it may never close the way SQL injection did.

Assume the injection works. Here are three ways it reaches your agent.

Your agents read email, tickets and documents you don’t control. A sentence in them becomes an instruction.

Your policy decides, whatever the model believed. An injected agent, a mistaken one and a misused one meet the same rule.

via an email it summarizesHidden text in the message tells the agent to forward what it can reach. The data leaves your tenant. Refused: no rule grants that action.
via a ticket it readsA poisoned ticket becomes a destructive write to production, authorized because the agent holds the credential. Held: this policy’s 2-of-2 quorum, not met.
via a document it fetchesA fetched page moves a payment to a new payee. Nothing records who authorized it, because nobody did. Held until the approvers this policy names have signed.

Anyone who can put text in front of an agent can act with its credentials: an email, a ticket, a PDF, a web page. Tool descriptions are the fastest-growing channel. OWASP LLM01:2025: no fool-proof prevention of prompt injection is known. UK NCSC, 2025-12-10: it may never close the way SQL injection did.

8.5%of indirect injections still succeed against the most injection-robust model measured, within 15 attempts
97%of breached organizations that had an AI-related incident lacked proper AI access controls

8.5%: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1,810 attacks, 15 attempts. 97%: IBM, Cost of a Data Breach 2025, n = 600 organizations, of the 13% that reported an AI breach. Chart: McKinsey Global Survey, “The state of AI in 2026: On the road to ROI,” n = 1,719, May–June 2026 (Exhibit 15).

Share working to mitigate each AI risk, % of respondents

AI high performersAll others
The gap appears only on the two risks about agent authority. The other two show none.
8.5%of indirect injections still succeed against the most injection-robust model measured, within 15 attempts
97%of breached organizations that had an AI-related incident lacked proper AI access controls

Share working to mitigate each AI risk, % of respondents

AI high performersAll others
The gap appears only on the two risks about agent authority. The other two show none.

8.5%: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1,810 attacks, 15 attempts. 97%: IBM, Cost of a Data Breach 2025, n = 600 organizations, of the 13% that reported an AI breach. Chart: McKinsey Global Survey, “The state of AI in 2026: On the road to ROI,” n = 1,719, May–June 2026 (Exhibit 15).

How it works

The agent proposes, your policy decides, your code executes, and a signed receipt proves it.

ZIFFER does not filter prompts. It checks actions. A manipulated agent holds no credential, so it cannot act on its own.

01 · Propose

Every action starts as a proposal. The agent holds one ZIFFER key. That key can ask, and it cannot act.

  • Through MCP, a coding agent gets the integration. The gate is the SDK’s verify line, in your own code.
  • Or one SDK call, or plain HTTPS. Your agent, model and prompts don’t change.
  • Least privilege you can show: there is no credential in the agent for an auditor to review. Why an agent should hold no credential

02 · Grant

Your policy decides. It grants routine actions with no one to wait for. It holds actions nobody can take back for your approvers.

  • Granted when your rules grade the action LOW
  • Held for a quorum when your rules grade it HIGH. Each approver signs the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists

03 · Execute

Your code executes. It runs an action only after it verifies the receipt, and only with your own credential.

  • The credential stays in your tool. Your code will not use it without a receipt it verified itself, offline, against ZIFFER’s public key.
  • Your auditor can test it: call your tool with no receipt, or with a receipt for other bytes, and watch your code refuse.
  • What was granted is exactly what ran. Your code hashes the bytes it holds and checks them against the receipt. It never trusts the message.

04 · Prove

A signed receipt proves what ran. The record keeps what the agent read. Nobody can change it afterwards.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Not us, not your own admin: nobody can change a record once it is written
  • Non-repudiation your auditor verifies with a public CLI, without production access

05 · Distribute

You sign your rules with your own key. ZIFFER never sees that key. Even a breached ZIFFER cannot rewrite your rules.

  • No runtime component holds a key that can produce a valid policy signature, so the runtime path has nothing worth stealing.
  • Policy Engine, KMS and Executor each verify the bundle independently, on every read: a service handed the policy by a peer would only be trusting that peer.
  • Change control: each new policy must carry a higher version number, so a rollback to yesterday’s looser rules is refused

How it works

The agent proposes, your policy decides, your code executes, and a signed receipt proves it.

ZIFFER checks actions, not prompts. A manipulated agent holds no credential, so it cannot act on its own.

01 · Propose

Every action starts as a proposal. The agent holds one ZIFFER key. That key can ask, and it cannot act.

  • Through MCP, a coding agent gets the integration. The gate is the SDK’s verify line, in your own code.
  • Or one SDK call, or plain HTTPS. Your agent, model and prompts don’t change.
  • Least privilege you can show: there is no credential in the agent for an auditor to review. Why an agent should hold no credential

02 · Grant

Your policy decides. It grants routine actions with no one to wait for. It holds actions nobody can take back for your approvers.

  • Granted when your rules grade the action LOW
  • Held for a quorum when your rules grade it HIGH. Each approver signs the exact bytes that will run. Silence is never consent.
  • Refused by default when no rule exists

03 · Execute

Your code executes. It runs an action only after it verifies the receipt, and only with your own credential.

  • The credential stays in your tool. Your code will not use it without a receipt it verified itself, offline, against ZIFFER’s public key.
  • Your auditor can test it: call your tool with no receipt, or with a receipt for other bytes, and watch your code refuse.
  • What was granted is exactly what ran. Your code hashes the bytes it holds and checks them against the receipt. It never trusts the message.

04 · Prove

A signed receipt proves what ran. The record keeps what the agent read.

  • Hybrid post-quantum signatures (Ed25519 + ML-DSA-65)
  • Not us, not your own admin: nobody can change a record once it is written
  • Non-repudiation your auditor verifies with a public CLI, without production access

05 · Distribute

You sign your rules with your own key. ZIFFER never sees that key.

  • No runtime component holds a key that can produce a valid policy signature, so the runtime path has nothing worth stealing.
  • Policy Engine, KMS and Executor each verify the bundle independently, on every read: a service handed the policy by a peer would only be trusting that peer.
  • Change control: each new policy must carry a higher version number, so a rollback to yesterday’s looser rules is refused

Who holds the keys

ZIFFER never holds your credentials. It never runs an action in your systems.

  • Your credentials stay in your own code. Your code runs a granted action after it verifies the receipt.
  • A gate that also runs actions can both authorize and perform. Then nothing is left to check it.
  • If ZIFFER were breached, the attacker would find no credential of yours.
  • The attacker could not sign or rewrite your rules. ZIFFER never sees the key that signs them.
  • Your approvers’ keys never leave their own devices.
  • ZIFFER does contact your approvers, by email, Slack or webhook. A notice carries a link, never an approve button.
  • In the Assured arrangement, your receipt keys sit in your own cloud account, so we cannot forge your receipts.

Who holds the keys

ZIFFER never holds your credentials. It never runs an action in your systems.

  • Your credentials stay in your own code. Your code runs a granted action after it verifies the receipt.
  • A gate that also runs actions can both authorize and perform. Then nothing is left to check it.
  • If ZIFFER were breached, the attacker would find no credential of yours.
  • The attacker could not sign or rewrite your rules. ZIFFER never sees the key that signs them.
  • Your approvers’ keys never leave their own devices.
  • ZIFFER does contact your approvers, by email, Slack or webhook. A notice carries a link, never an approve button.
  • In the Assured arrangement, your receipt keys sit in your own cloud account, so we cannot forge your receipts.

◆ What you hand the auditor

Every action gets one line on the record. Each line shows what was proposed, what your policy decided, and who signed.

◆ What you hand the auditor

Every action gets one line on the record. Each line shows what was proposed, what your policy decided, and who signed.

The sign-off checklist

Six properties you can check before you sign off. Four of them cite a published clause, shown under the title.

Zero credentials in the agent

The agent holds no secret, not even a short-lived or brokered one. Nothing can leak into a context window.

Proof of every action

Your agent platform shows what the agent saw. Every ZIFFER receipt proves what it was allowed to do: the action, the policy version, who approved, and the decision.

Refusal by default

8.4-3 · P-4

An action with no rule is refused, never graded. Unknown risk is never LOW.

Approval is explicit and tied to the exact action

AC-3(2)

Dual authorization: your signed policy sets the quorum of named humans, and each one signs the exact bytes that will run. The proposer cannot approve their own action.

A signed receipt for every allowed action

AU-10 · AU-3

Only an allowed action gets a KMS-signed receipt, binding the action, its rules and the humans who signed. A refusal or an expiry leaves a decision record.

History nobody can rewrite

AU-9(3)

Records are only ever added, never changed. They are published outside ZIFFER before an irreversible action runs.

The clause IDs are real. ZIFFER implements an open specification with machine-checked proofs and a public conformance suite. Every claim replays on your machine: ./tools/verify.sh --suites

The sign-off checklist

Six properties you can check before you sign off. Four of them cite a published clause, shown under the title.

Zero credentials in the agent

The agent holds no secret, not even a short-lived or brokered one. Nothing can leak into a context window.

Proof of every action

Your agent platform shows what the agent saw. Every ZIFFER receipt proves what it was allowed to do: the action, the policy version, who approved, and the decision.

Refusal by default

8.4-3 · P-4

An action with no rule is refused, never graded. Unknown risk is never LOW.

Approval is explicit and tied to the exact action

AC-3(2)

Dual authorization: your signed policy sets the quorum of named humans, and each one signs the exact bytes that will run. The proposer cannot approve their own action.

A signed receipt for every allowed action

AU-10 · AU-3

Only an allowed action gets a KMS-signed receipt, binding the action, its rules and the humans who signed. A refusal or an expiry leaves a decision record.

History nobody can rewrite

AU-9(3)

Records are only ever added, never changed. They are published outside ZIFFER before an irreversible action runs.

The clause IDs are real. ZIFFER implements an open specification with machine-checked proofs and a public conformance suite. Every claim replays on your machine: ./tools/verify.sh --suites

Pricing

Three arrangements. They differ in who holds your receipt keys and who checks you.

Available now

Standard

“Do you check yourself?”

Who it is for: Teams putting their first AI agents into production, who check their own controls.

  • Hosted ZIFFER, admin & approval consoles
  • Signed receipts, per-tenant signing key
  • Hosted external anchoring, auditor CLI
  • MCP / SDK / HTTPS integration
  • Onboarding starts within 48 hours
Book a 30-min sign-off review →
On request

Assured

“Does someone independent check you?”

Who it is for: Companies whose auditors or enterprise customers want proof checked by someone other than the vendor, with the signing keys in their own cloud so ZIFFER cannot forge a receipt.

  • Verification runs outside production, by a party with no production credential
  • Receipt keys in your cloud account: we cannot forge your receipts, and you can revoke us
  • Every signature lands in your audit trail
Book a 30-min sign-off review
On request

Regulated

“Does a regulator dictate how your keys are held?”

Who it is for: Banks, payment and health companies whose regulator dictates how signing keys are held.

  • Mandated custody arrangements
  • HSM-held keys under external mandate
  • For deployments where the key mechanism is prescribed
Book a 30-min sign-off review

Read the full pricing page

Pricing

Three arrangements. They differ in who holds your receipt keys and who checks you.

Available now

Standard

“Do you check yourself?”

Who it is for: Teams putting their first AI agents into production, who check their own controls.

  • Hosted ZIFFER, admin & approval consoles
  • Signed receipts, per-tenant signing key
  • Hosted external anchoring, auditor CLI
  • MCP / SDK / HTTPS integration
  • Onboarding starts within 48 hours
Book a 30-min sign-off review →
On request

Assured

“Does someone independent check you?”

Who it is for: Companies whose auditors or enterprise customers want proof checked by someone other than the vendor, with the signing keys in their own cloud so ZIFFER cannot forge a receipt.

  • Verification runs outside production, by a party with no production credential
  • Receipt keys in your cloud account: we cannot forge your receipts, and you can revoke us
  • Every signature lands in your audit trail
Book a 30-min sign-off review
On request

Regulated

“Does a regulator dictate how your keys are held?”

Who it is for: Banks, payment and health companies whose regulator dictates how signing keys are held.

  • Mandated custody arrangements
  • HSM-held keys under external mandate
  • For deployments where the key mechanism is prescribed
Book a 30-min sign-off review

Read the full pricing page

Objections, answered

The questions your approval meeting will ask.

Doesn’t waiting for two humans kill agent speed?

Most of the day passes untouched. Only actions nobody can take back are held, so the holds are rare. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. Each hold reaches the approver with the facts already recorded: who proposed the action, what the agent had read, and what the action would do. A grant can be revoked without touching the agent.

Why not build this with our own IAM?

Your IAM answers whether an identity may reach a system. It does not answer whether this action should happen. You can build the check loop in a weekend. The rest takes longer: machine-checked proofs, hybrid post-quantum signed receipts, an externally anchored ledger your own admin cannot rewrite, and a public conformance suite that proves all of it. If you do build it, build to the open specification. The suites will tell you what your version misses.

How long does integration take, and what changes for the agent team?

Minutes on the agent edge. Your tool code adds one SDK call to propose and one line to verify the receipt, and plain HTTPS works too. Through MCP, a coding agent gets that integration. The credential stays in your tool, and your code will not use it without a receipt it verified itself. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

What do I get from the sign-off review?

Thirty minutes, and you leave with a sign-off memo rather than a deck: your rollout’s properties mapped to the controls you already own, the list of actions we would hold for a quorum of named humans, and a sample of the evidence an auditor would receive. If the honest answer is that you don’t need us, the memo says that.

Objections, answered

The questions your approval meeting will ask.

Doesn’t waiting for two humans kill agent speed?

Most of the day passes untouched. Only actions nobody can take back are held, so the holds are rare. A gate that fires on everything is approved on reflex, and OWASP lists that reflex as a threat of its own. Each hold reaches the approver with the facts already recorded: who proposed the action, what the agent had read, and what the action would do. A grant can be revoked without touching the agent.

Why not build this with our own IAM?

Your IAM answers whether an identity may reach a system. It does not answer whether this action should happen. You can build the check loop in a weekend. The rest takes longer: machine-checked proofs, hybrid post-quantum signed receipts, an externally anchored ledger your own admin cannot rewrite, and a public conformance suite that proves all of it. If you do build it, build to the open specification. The suites will tell you what your version misses.

How long does integration take, and what changes for the agent team?

Minutes on the agent edge. Your tool code adds one SDK call to propose and one line to verify the receipt, and plain HTTPS works too. Through MCP, a coding agent gets that integration. The credential stays in your tool, and your code will not use it without a receipt it verified itself. Onboarding starts within 48 hours. Your agent, model, framework and prompts don’t change.

What do I get from the sign-off review?

Thirty minutes, and you leave with a sign-off memo rather than a deck: your rollout’s properties mapped to the controls you already own, the list of actions we would hold for a quorum of named humans, and a sample of the evidence an auditor would receive. If the honest answer is that you don’t need us, the memo says that.

Bring us the rollout you are asked to approve.

In thirty minutes, you leave with the memo you would sign.

Book a 30-min sign-off review →

Onboarding within 48 hours · open spec · verify before you pay

Bring us the rollout you are asked to approve.

In thirty minutes, you leave with the memo you would sign.

Book a 30-min sign-off review →

Onboarding within 48 hours · open spec · verify before you pay