What ZIFFER does not do yet

The rest of this section documents what runs today. This page is what does not, so that nobody has to discover it.

• The SDK verifies; it does not intervene. verify raises or returns. Nothing in it sits between your agent and its credentials. The line that stops the action is a line of your code, and you have to write it.
• There is no replay protection in your process. The claims that make a receipt single-use are made against a ledger inside our deployment. A receipt your handler verified once will verify again. Make your own execution idempotent, on your own key, the way you would without us.
• The MCP server routes; it does not enforce. It runs on a developer's machine at development time and has no hands on your production path. An agent that has talked to it has not thereby been gated by anything.
• The trust anchor's freshness is yours to manage. There is no revocation channel and no expiry on the anchor itself. Rotation today is: we tell you, you replace the file.
• Nothing here is an audit trail. The SDK does not store, forward or log receipts. A verified receipt you threw away is a check you can no longer show anyone.
• A sandbox is a separate tenant, not a dry run. Your handler still performs the action. A sandbox grant handed to a handler that transfers money transfers money.
• A sandbox grant means the path worked, not that anyone agreed. The approver is a robot, and its signed summary says in words that no human reviewed the action.
• A sandbox approves everything the policy admits. Testing that your policy refuses something is a real test there. Testing that an approver would refuse is not, because there is nobody to refuse.
• Nothing on our side stops you pointing production at a sandbox anchor. The separation holds while the two anchors stay apart, and that is one path in your configuration.
• The executor does not run on your infrastructure yet. It can pull its work, which is the shape a customer-premises executor will use. The deployment it pulls into is still ours.
• The consumption ledger is inside our perimeter. It is the store the single-use claim is made against, and an executor outside cannot reach it. This is the largest of the gaps, because the safety argument for pull delivery is a claim against a store the puller cannot read.
• Audit append and the covering anchor are inside our perimeter. A covering anchor is required before a high-risk release, so an executor that cannot reach the audit service cannot release at high risk at all. Not loses some evidence: cannot release.
• The live capability re-check is inside our perimeter. From outside, that leg is absent rather than degraded.
• Human acknowledgement arrives inbound, from us. An executor with no inbound route from our cloud has no held action, no acknowledgement and no repudiation, which is the entire high-risk release path.
• There is no mechanism for moving your signed bundle to a host we do not operate. Without policy to verify against, the executor refuses rather than proceeds. Correct, and not operable.
• Our executor image ships with no SBOM and no build attestation. The whole argument of this arrangement is that you verify instead of trusting us, and this is the one place in it where you cannot. It is recorded as open.
• A stolen pull certificate can suppress work. It cannot cause an effect, because that needs your credential. It can read your pending work, and it can complete a sequence number your executor never polled, which marks that work done. That is a denial rather than a forgery, and nothing today detects it.
• There is no human approval surface. An approver holds a key file today and signs with it. In a sandbox, a robot approves.
• Nobody is emailed. The notification service resolves the name of a notice target to a file today, not to a mailbox. The mapping and the mail channel are the next build.
• A policy update after your first bundle does not take effect until we restart the services that read policy. Your first bundle is placed at enrolment and works.