Zipwire | The Coming AI Curtain: National Security, Frontier Models, and What We Risk Losing

Luke Puplett Founder

The dilemma nobody wants to talk about honestly

Something uncomfortable is happening at the frontier of AI access. Models capable of accelerating materials research, automating financial analysis, generating synthetic media at scale, and—in the wrong hands—assisting with things nobody should be assisting with are being deployed as general-purpose APIs. And regulators, quite reasonably, are asking: who exactly is on the other end of those API keys?

The honest answer is: providers often don't know. And in some cases, they're legally required to know.

US export control law already classifies certain AI hardware and model weights. The EU AI Act creates risk tiers. AML obligations follow AI systems embedded in financial workflows. The calls to extend identity verification to model access—"AI passports," nationality gates, mandatory KYC for API keys—are getting louder, and they come from serious people with serious arguments.

But if building a global identity checkpoint into the web's most important new infrastructure layer becomes the default answer, it's worth pausing to ask where that leads. The internet's open architecture has been one of the most powerful forces for human knowledge, connection, and resistance to authoritarian control in history. Every layer of mandatory verification we bolt onto it is a layer that tends to stay.

None of this is invented. The regulatory pressure has legal teeth, the misuse cases are documented, and the cost of getting the answer wrong in either direction is high.

There's a third path. It requires cryptography, not compromise.

What providers are actually trying to prevent

It's worth being precise about what legitimate gatekeeping looks like, because the concerns get lumped together in ways that confuse the debate.

Export control compliance. Certain AI capabilities may be legally restricted under national security rules. This is a real obligation with real legal consequences for providers—not a preference.
Sanctions screening. Persons or entities on sanctions lists cannot legally receive services from many providers regardless of capability tier. This is standard AML practice applied to a new surface.
Automated abuse at scale. Bot farms, prompt injection pipelines, credential harvesting, synthetic media generation at volume: these are operational threats with economic and reputational consequences for providers.
State-sponsored disinformation infrastructure. Coordinated influence operations running through AI APIs are not a theoretical risk. They've been documented. Providers have both legal and ethical reasons to want to prevent this.
Regulated downstream applications. AI systems in finance, healthcare, and legal services carry domain-specific compliance requirements. Providers building pipelines into those sectors need to know who's on the other end.

None of these concerns are invented. The problem is that the solutions being proposed—nationality document uploads, blanket geoblocking, mandatory passport verification for API access—are not well-matched to the actual risk model.

Why blanket checks fail, and why they matter

Nationality-based access control has a fundamental flaw: nationality is a very coarse proxy for risk, and a very blunt instrument for compliance.

The person in Tehran building a translation tool for a human rights NGO gets blocked. The state actor in a permitted jurisdiction running a disinformation operation does not. The researcher in Shanghai studying AI alignment can't access the model they're studying. The well-resourced bad actor with a VPN and a corporate entity in an approved country breezes through. The check stops the legitimate marginal case and fails to stop the determined bad actor. That's the worst possible trade-off.

VPNs make geoblocking trivially circumventable for anyone technically motivated. The signal is easily spoofed, which means you end up with friction for legitimate users and false confidence about bad ones.

But the deeper problem is structural. Once you build national identity verification into API access flows, that infrastructure exists. It can be extended—by you under future regulatory pressure, by acquirers, by government request. The export control check you add today becomes the foundation for something else tomorrow. History suggests we should be cautious about building that foundation at all.

There's also the chilling effect on exactly the users the web has most benefited. Dissidents, journalists, academics, independent researchers, developers in countries with authoritarian governments who are building tools to circumvent that control: these people depend on an internet that does not demand papers at every door. A mandatory identity layer for AI access is a gift to every government that wants to know who its citizens are learning from.

This is not a reason to ignore legitimate compliance obligations. It's a reason to be very precise about what those obligations actually require—and to find solutions that meet them without building surveillance infrastructure.

The better path: prove the predicate, not the person

We already accept a version of this. IP geofencing — restricting access based on the geographic origin of a connection — is woven into the fabric of the web. Streaming services use it for content licensing. Fintech apps use it for regulatory compliance. Most people tolerate it as a reasonable trade-off, even knowing it's trivially bypassed with a VPN.

The question now being posed is whether to fix IP geofencing's limitations by escalating to full identity verification. But there's a different question worth asking: what if we replaced IP geofencing rather than supplemented it? A user's wallet can carry a cryptographic attestation of their nationality — issued after a real government ID check, verifiable by any service, anonymous to the verifier. The provider gets a stronger, unforgeable signal than an IP address ever gave them. The user gives up nothing beyond what they'd give up for the ID check itself. And there's no centralised checkpoint that can be repurposed or extended.

Selective disclosure makes this possible. Instead of handing over an identity document, a user proves a predicate: a statement about themselves that is cryptographically bound to a verified identity without revealing that identity. "My nationality is UK." "I am not on a sanctions list." "I am over 18." The verifier gets the answer to their compliance question and nothing else.

The underlying identity document never leaves the user's control. The verifier holds no PII. There's no central record of who checked what. The proof is reusable across any service that trusts the attestation issuer. And it works for AI agents as well as humans—which matters enormously in an agentic world.

Zipwire Attest: building the human root

Zipwire Attest takes a user through a government-approved Yoti ID check—the same verification standard used by UK banks—and produces on-chain attestations to the user's Ethereum wallet via EAS (Ethereum Attestation Service) on Base.

There are two attestation types:

IsAHuman — A boolean proof of personhood. This wallet belongs to a verified human. No personal data is attested, just the fact of having passed a government-approved ID check. Useful for bot gates, DAO voting, and any scenario where the only question is "human or not."
Private Data — A Merkle root attestation. Zipwire builds a Merkle tree from the user's ID document data (and optional AML background check), then attests only the root hash to the blockchain. No personal data goes on-chain—just a cryptographic fingerprint. Individual data fields (nationality, date of birth, AML status) live as leaves in that tree. Users can prove any individual leaf without revealing the others.

The architecture is deliberately open. Any KYC/ID provider can issue EAS attestations following the same standard. Services configure which attester addresses they trust—Zipwire's, Coinbase's, a government entity's. One verification flow; many possible trust roots.

ProofPack: carrying claims from attested documents

When a document check completes, the verified data doesn't have to disappear into a compliance database. ProofPack is the format that lets it travel with the person instead.

The flow is straightforward. After a document check — a passport verified by Yoti, a driver's licence, or even a bank statement where the bank is the attesting party — the issuer builds a Merkle tree from the verified fields: nationality, date of birth, address, AML status, account tenure, whatever the document contained. The root hash of that tree is attested on-chain via EAS. The person then holds a ProofPack: a cryptographically signed package that can selectively reveal any field, or combination of fields, while proving mathematically that they come from that attested document.

When they present it to an AI service, they choose what to disclose. A nationality gate only needs to see nationality. An AML check only needs AML status. The rest stays hidden. The service verifies the proof locally against the on-chain attestation — no call back to the issuer, no record kept of who verified what.

The attester doesn't have to be Zipwire. Any issuer can participate provided the service is configured to trust their attester address. A bank attesting a bank statement, a government portal attesting a driving licence, a payroll provider attesting employment — the verification flow is identical. One library, many possible trust roots. ProofPack's role in broader selective disclosure contexts is covered in more depth in ProofPack: Tokenizing Real-World Assets with Selective Disclosure.

Verification (Node.js)

import { AttestedMerkleExchangeReader, AttestationVerifierFactory,
         JwsSignatureRequirement, createVerificationContextWithAttestationVerifierFactory } from '@zipwire/proofpack';
import { EasAttestationVerifierFactory, ES256KVerifier } from '@zipwire/proofpack-ethereum';

// Configure EAS network (Base mainnet or Sepolia for testing)
const easVerifier = EasAttestationVerifierFactory.fromConfig({
    'base': { rpcUrl: process.env.RPC_URL, easContractAddress: '0x4200000000000000000000000000000000000021' }
});

const verificationContext = createVerificationContextWithAttestationVerifierFactory(
    24 * 60 * 60 * 1000, // max token age: 24h
    (alg, signers) => alg === 'ES256K' ? new ES256KVerifier(signers[0]) : null,
    JwsSignatureRequirement.AtLeastOne,
    async (nonce) => /^[0-9a-fA-F]{32}$/.test(nonce),
    new AttestationVerifierFactory([easVerifier])
);

const reader = new AttestedMerkleExchangeReader();
const result = await reader.readAsync(jwsFromRequest, verificationContext);

if (result.isValid) {
    // Leaves are disclosed fields from the attested document
    const leaves = result.document.merkleTree.leaves;
    // Parse the leaves you need and apply your policy
    // Full parsing guide: github.com/zipwireapp/ProofPack
}

Install: npm install @zipwire/proofpack @zipwire/proofpack-ethereum. For the .NET equivalent and full examples see the ProofPack repository.

What AI providers can actually do with this

Tier advanced capabilities behind a compliance proof. Gate fine-tuning access, high-rate API tiers, or specific model features behind a nationality and sanctions check—without demanding full identity documents. Users prove the predicate; providers apply their export control rules. The check is proportionate to the actual compliance requirement.
Accept proofs from multiple trusted issuers. A user might hold a Zipwire-attested passport proof, a bank-attested financial proof, or a government-issued driving licence proof. Configure the attester addresses you trust; the verification flow is the same regardless of who issued the proof.
Gate regulated API surfaces proportionately. Financial AI, health AI, legal AI: these carry domain-specific compliance requirements. ProofPack lets you enforce them at the API layer—AML status, age verification, professional credentials—without building an identity database into every endpoint.

The pattern in every case: configure trusted attester addresses, receive a ProofPack, verify locally, act on disclosed claims. One integration; many compliance postures. No PII stored at the provider, no surveillance layer that can be repurposed.

What's shared and what isn't

It's worth being precise about what the verifier actually sees in this model:

On-chain: Only the Merkle root hash. No name, no date of birth, no nationality—just a cryptographic fingerprint that lets proofs be validated against it.
In the JWS: Only the leaves the user chose to disclose. If they're proving nationality and AML status, those two fields are revealed. Everything else—date of birth, address, ID number—remains hidden behind the Merkle structure.
At verification time: The disclosed claims and a validity signal. Verification is local—no call to Zipwire, no logs at Zipwire of who verified what, no third-party knowing which service the user is accessing.
Revocability: Attestations can be revoked on-chain. ProofPack checks revocation status as part of verification. A stolen or compromised proof can be invalidated without touching the underlying identity.
Replay protection: Timestamps and nonces are baked into the JWS envelope. A captured token has a limited lifetime and cannot be replayed indefinitely.

The internet worth protecting

The access control problem for frontier AI is real, and it isn't going away. The regulatory pressure will intensify. The misuse cases will get more sophisticated. Providers genuinely need tools that let them meet their compliance obligations.

But there are two ways to build those tools. One builds a surveillance layer: collect identities, store documents, create logs of who accessed what, hand over data on request, extend the system over time. The other asks only the question that needs answering and records nothing else.

The first approach is what we'd call pragmatic. The second requires a bit more engineering. But the second is also the one that's compatible with the internet as it exists—a global commons that has, with all its imperfections, allowed people in authoritarian countries to access uncensored information, allowed researchers to collaborate across national boundaries, and allowed developers anywhere to build things that matter.

That's worth protecting. And it's possible to protect it while still meeting the compliance requirements that are genuinely real.

Get started

Get attested: Zipwire Attest — Yoti ID check, IsAHuman and Private Data attestations to your wallet.
Verify ProofPacks: github.com/zipwireapp/ProofPack — npm and NuGet packages, examples, HTTP header guide.

The Coming AI Curtain: National Security, Frontier Models, and What We Risk Losing