Provisioned Trust Infrastructure (PTI)

PTI in one paragraph

Provisioned Trust Infrastructure (PTI) is a trust model in which the parties to a transaction already hold a key relationship before the transaction begins, rather than negotiating one when it starts. Keys are symmetric, AES-256. The first key is loaded through an authenticated out-of-band ceremony; every later key — rotation, addition, role change, revocation — is delivered wrapped under a key already held. Because the relationship pre-exists, no public-key operation is performed on the provisioned transaction path: no certificate to validate, no chain to walk, no certificate revocation list to distribute at transaction time. Current identity and key-revocation status must still be checked. Authority is bound to the individual transaction and checked before the operation executes, rather than inherited from an authenticated session.

• Symmetric cryptography, AES-256, on the provisioned transaction path.
• Every actor — human or autonomous — individually identified, authorised, revocable and accountable.
• Within the domain, the instruction, the access evidence and the system state commit together, so movement and authority are not reconciled after the fact.
• Precedents in production at scale: symmetric online card authorisation, mobile subscriber authentication, and the symmetric key-block standards used between secure cryptographic devices.

How does PTI make the permission boundary enforceable?

A PTI domain is fully mediated when every sensitive operation it is meant to protect passes through an intact, non-bypassable enforcement point that checks transaction-specific authority before the operation runs. Five conditions make that true in practice:

• Keys are issued by a trusted issuer outside the workloads that use them.
• Rules express the intended limits — operations, resources, destinations, ceilings, validity — for each actor class.
• Validation is independent: the enforcement point verifies the request itself and does not accept the caller's own assertion.
• Keys are protected: workloads receive only permitted transaction-key use. Agent-level derivation keys and unrestricted parent or root keys remain inside protected key services, outside the workload’s control.
• State is fresh and fail-closed: if current registration, revocation or policy state cannot be confirmed, the request is denied.

Under these conditions, a protected operation cannot proceed without valid transaction-specific authority. The boundary covers mediated operations, not plaintext already accessible inside a process or systems outside the domain. Secure implementation and deployment are essential to this property.

Autonomous AI agents

Can PTI address the “rogue AI” problem? What does giving every AI agent its own identity actually achieve?

At the infrastructure layer, the question is whose authority an agent uses and whether that authority is checked before each action. Some agents inherit a human session; others already have scoped service identities. Wherever either arrangement grants broad, reusable authority without per-action checks, task drift can produce harmful but technically permitted activity. PTI ties authority to the protected operation instead of treating a successful login as continuing permission.

Identity is necessary but not sufficient. PTI gives distinct identities to the agent, to the responsible principal on whose behalf it acts, and to the service or workload it runs in, and carries origin and delegation through every hop — proxies, queues, workers — so the party that finally executes an operation knows which agent asked, under whose responsibility, with what permitted scope. What turns identity into control is binding authority to one transaction and checking it before execution.

How is an agent's authority bound to a single transaction?

Through two keys, both derived by a trusted issuer and never by the agent. An agent key, K_agent, is derived from a structured, unambiguous, domain-separated context: actor ID and class, responsible principal, issuer, permitted scope, validity window, key and policy version. A transaction key, K_tx, is derived inside the protected issuer from K_agent and the transaction context: unique transaction ID, operation, resource, destination, limits, expiry, version. The request is authenticated under K_tx with a MAC or authenticated encryption plus anti-replay state, so the verifier authenticates exactly this request, not a class of requests resembling it. Conceptually, K_agent = KDF(issuer key, agent context) and K_tx = KDF(K_agent, transaction context) — explanatory design, not the disclosed production algorithm.

Three points about what this proves. Authority can only narrow along the chain because the issuer and the verifier enforce it; a key derivation function alone does not enforce subsets, which is why no unrestricted parent or root derivation key is ever placed in an agent workload. Under the cryptographic assumptions, a valid MAC authenticates the message to a holder of the relevant key — not a unique physical identity, and not benign intent. And a request whose context does not match — tampered, replayed, or outside the bound scope — is rejected at the enforcement point before the covered action executes. It is not impossible to formulate; it is refused.

Which GVE ID modules make this operational?

• Global ID Registration DB — the agent is registered as an access object in its own right, carrying its actor class, its responsible principal, its delegation parent and depth, and its revocation status.
• Mutual Identification (PTI) — authenticates the actor, both ends, before any service runs, resolving its class from the Global ID Registration DB. The agent is authenticated as itself, not under the human's credentials.
• Rules — ceilings, scope lifetime, maximum delegation depth, and the operations, resources and destinations each actor class may request.
• Authorization — issues and binds the exact authorised scope for one transaction, expressed as a transaction key derived under the agent key.
• Rule Engine & Dispatcher — validates what each step actually requests against that bound scope as it routes, and rejects out-of-scope, tampered or replayed requests before the covered action executes.
• The Account and Global ID Registration data bases, and the Transaction Data Base — record what the actor was, under whose responsibility, and the per-step verification results and outcomes.

Three consequences follow. Requests outside the enforced scope are refused at the next protected operation. Identity-based revocation provides a coordinated way to withdraw authority, subject to propagation and enforcement checks. And the record distinguishes the agent’s actions from its principal’s actions. Identity directories establish who was registered; PTI adds transaction-specific authority and enforcement before execution.

What does revocation actually stop?

New authorisations. Once revocation has propagated — a bounded interval that a deployment must measure rather than assume — no new transaction key is issued for the identity, and every fresh check denies its subsequent requests. Operations already running under previously issued authority are a separate matter and must be stopped explicitly; a deployment that needs containment pairs revocation with the ability to isolate or terminate the affected workloads.

Could PTI prevent an incident like the Hugging Face intrusion?

Hugging Face's technical timeline describes an autonomous agent abusing its dataset-processing pipeline in July 2026. HDF5 external-file references first caused a worker to return local files, including credentials, without code execution. Jinja template injection then enabled code execution, followed by stolen-token use, privileged infrastructure access and lateral movement. Data left through legitimate platform APIs and attacker-controlled datasets. The security stack correlated attack signals but failed to trigger critical on-call response promptly.

The architectural comparison identifies three boundaries that a fully mediated PTI deployment could enforce. It is not a claim of demonstrated prevention in the Hugging Face environment:

• Upload is not read. An identity authorised to upload a dataset holds no transaction authority to read the worker's environment or source; a parse job requesting secrets is out of scope and refused.
• Parse is not execute. A processing identity is not authorised to execute arbitrary code, create privileged pods or request new tokens; each needs separate, bound authority it does not hold.
• An allowed destination is not an authorised disclosure. The platform API and a dataset repository are permitted destinations for processing output; committing protected secrets to them is a different operation, and egress of protected data is covered in its own right.

Each boundary requires mediation of file access, runtime execution, cloud and cluster API calls, and egress, with isolated workloads and minimal credentials. Secrets already accessible inside a process and operations outside the domain are not protected automatically. Sender-side PTI alone cannot govern a platform’s internals; enforcement must extend to those internal operations. Such coverage could block critical unauthorised stages in this chain. The structural benefit is refusal before an out-of-scope operation executes. Harm within genuinely granted permissions still requires complementary controls, including isolation, least privilege and detection.

What does PTI add to real-time audit and detection?

Every enforcement decision produces a record tying together identity, delegation chain, the exact request, the decision and the outcome. Because refusals are made synchronously at the enforcement point, an unauthorised request is denied when made rather than discovered later. On that record, continuous policy-violation detection can be configured: repeated out-of-scope requests, delegation-depth breaches or use from unexpected origins page the on-call team at critical severity, trigger containment, revoke the affected delegations and isolate or stop the workers involved. GVE does not advertise a universal real-time detector or a measured latency figure: denial is synchronous where enforcement is in place; detection, paging and revocation latency belong to a specific deployment and are measured there.

Quantum

Is PTI secure against quantum computers, given that it does not use NIST PQC?

PTI removes the quantum-vulnerable public-key attack surface from the provisioned transaction path. No RSA, Diffie–Hellman, elliptic-curve or ECDSA operation is performed there, so Shor's algorithm — which targets integer factorisation and discrete logarithms, not AES — has nothing on that path to attack. Rails whose certificates rest on those algorithms face a migration; in a provisioned domain the target is absent.

NIST has standardised quantum-resistant public-key algorithms: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. PTI complements these approaches in provisioned domains; PQC can protect non-provisioned external interfaces. The EU transition roadmap also recognises symmetric alternatives where appropriate to the application. Removing quantum-vulnerable public-key dependencies is not a claim that quantum computing has no effect on symmetric security.

What about Grover's algorithm against AES-256?

Grover's algorithm is a generic square-root speed-up on key search. Taken at face value it puts a generic AES-256 key search at roughly 2^128 queries to an idealised quantum AES oracle — a statement about the cipher's key space, not a claim that a whole system has 128-bit security. NIST's assessment is that Grover parallelises poorly, is likely to give little or no practical advantage against AES, and that AES-192 and AES-256 should remain safe for a very long time absent new cryptanalytic weaknesses. NIST Security Category 5 is defined by reference to AES-256 key recovery; it is a benchmark for comparing algorithms, not a certification of PTI. In a real system the MAC length, key derivation function, random number generator, nonce handling, implementation quality and key management also determine the security delivered.

Does PTI withstand Harvest Now, Decrypt Later attacks?

The public-key-break form of HNDL records traffic today and breaks the key-establishment operation later. The route is removed only where the first key, all subsequent key establishment and the payload protection are independent of quantum-vulnerable public keys; running AES after an RSA or ECDH exchange does not remove it, because the recorded exchange is the target. On PTI's provisioned transaction path there is no public-key exchange to record: the first key is loaded through an authenticated out-of-band ceremony and every later key is wrapped under a key already held.

Two qualifications. The out-of-band provisioning must itself meet that standard — a branch or ATM flow is an operational channel, not automatic proof. And wrapping and rotating keys under an existing key does not by itself give forward secrecy or restore security once the wrapping key is compromised; recovery needs independently protected trust material. Control plane, TLS, software and firmware updates, enrolment, recovery and every external interface require their own assessment.

Keys

Doesn't distributing the keys require public-key cryptography?

Not on PTI's key-provisioning path. The first key is loaded through an authenticated, secure out-of-band ceremony, so it is never recovered through public-key-dependent wrapping; every later key is wrapped under a key already held. The three routes:

Recovery after a compromise uses independently protected trust material — a fresh ceremony or a separately held recovery key — never the compromised key. For institutions the framing is simpler still: the endpoints are counterparty systems and the hardware security modules behind them, belonging to organisations already contracted and onboarded, and loading a first key is the key ceremony those institutions already run for interbank messaging keys. No manufacturer, mobile operator or platform vendor is involved.

If there are no certificates, what replaces the certificate chain?

Nothing replaces it, because the question it answers is not asked. A chain lets a verifier that shares no prior secret with a prover decide whether to trust it. Inside a provisioned domain the verifier already stands in a key relationship with the authority that provisioned the prover: no certificate authority to build, no chain to validate at transaction time, no certificate revocation list to distribute, no certificate lifecycle to operate. Current identity and key-revocation status must still be enforced.

Isn't a central key authority a concentration of risk?

Yes. A provisioning authority must be protected through hardware-backed key custody, separation of duties, least privilege, audit and tested recovery. A compromise of that authority can affect its domain. Certificate-based systems also concentrate trust in issuing authorities, but neither model makes this risk disappear. PTI makes the provisioned domain explicit so that its governance and failure boundaries can be assessed.

Evidence and assurance

A symmetric authenticator gives no non-repudiation. How is that addressed?

By architecture, and with a precise claim. An asymmetric signature gives a property the verifier could not have produced; a message authentication code does not, because prover and verifier both hold the key. PTI meets the evidential requirement the way financial infrastructure already does: verification sits with a party that is neither of the two transacting parties, and that party's record is tamper-evident — the evidence that a card authorisation cryptogram was valid is the issuer's verification record, not something the cardholder signed. MAC-based records support evidence when paired with independent controls — separation of duties, protected logging, independent time and key custody — but they are not asymmetric non-repudiation and are not universally accepted by courts as such; their weight is decided forum by forum.

Beyond that, GVE's architecture gives an endpoint an independent means of attesting which requests it actually originated, retained at the endpoint and not derivable from the infrastructure's records. By prior arrangement the attestation can be made verifiable by a nominated independent party, so a court or auditor is not asked to take the operator's word. This is a detection and dispute-resolution property, not a preventive control. It is described by GVE; the mechanism is not published, and its precise guarantees await independent evaluation.

Symmetric authentication sounds unusual. Is there precedent at scale?

It is the opposite of unusual. A very large share of the world's authentication traffic already runs this way, at scale, under scrutiny, for decades.

• Online card authorisation computes an authorisation cryptogram under symmetric keys derived from an issuer master key, and the issuer answers with a response cryptogram. The issuer’s cryptogram check is symmetric; other parts of a card-payment system can also use public-key signatures.
• Mobile subscriber authentication (3GPP AKA) authenticates a subscriber module to its home network on a long-term shared symmetric key, with MILENAGE built on AES.
• Kerberos in its base form is symmetric and centred on a key distribution centre.
• ANSI X9.143 (TR-31) key blocks start from the premise that two secure cryptographic devices already share a symmetric wrapping key — PTI's starting point, written into an ANSI standard.

These precedents demonstrate that provisioned symmetric trust can support authentication at scale. They establish the viability of the trust model, not the security of a particular PTI implementation.

How can a design be trusted if it is not published?

Through independent evaluation against a defined security scope. GVE's implementation is proprietary. Common Criteria (ISO/IEC 15408) provides an assurance route through a Security Target, laboratory evaluation and a certification report. Any certification claim must identify the product version, certificate and evaluated scope. Architectural alignment alone does not prove security, and this FAQ does not claim an existing PTI certification. Proprietary implementation details can remain confidential to evaluators.

How should an institution test these claims before relying on them?

Replay a real incident. Take a documented attack chain — the Hugging Face timeline is a public example — reproduce each stage in a test domain, and record which steps the enforcement point denies and which it lets through. Measure, rather than assume, the time from policy violation to alert, to paging and to revocation taking effect, and confirm that already-running workloads are actually stopped. The results belong to the tested deployment; GVE publishes no figures ahead of such a test.

Adoption and cost

How does the cost compare with a migration to NIST PQC?

GVE's scenario estimates for global financial infrastructure — banking, payments and market infrastructure — cumulative over 2026–2035, in 2026 US dollars. They are GVE's own modelling, not independent validation, and not a promise of savings for any particular institution.

Pairing the low-cost estimates (USD 90 billion and USD 30 billion) gives a USD 60 billion difference; pairing the high-cost estimates (USD 200 billion and USD 70 billion) gives USD 130 billion. These are illustrative paired-scenario differences, not the full range of possible outcomes or guaranteed savings. Migration durations are shown separately in the table.

GVE’s model assumes reduced certificate infrastructure and concentrated key operations within the provisioned domain. PTI still requires identity and key-revocation controls, secure provisioning, integration and operations. Where device and provisioning assessments support reuse, terminal upgrades and card reissuance may be avoided; compatibility and resulting savings are deployment-specific.

Public transition plans provide context, not validation of PTI costs. NIST IR 8547 is an initial public draft proposing transition milestones for affected public-key algorithms, not a binding universal deadline. The EU roadmap targets high-risk use cases by end-2030, medium-risk by end-2035 and low-risk as far as feasible. UK NCSC guidance targets planning by 2028, highest-priority migrations by 2031 and completion by 2035.

GVE's modelling uses public reference points: ONCD's approximately USD 7.1 billion projection in 2024 dollars for prioritised federal systems over 2025–2035, excluding separately estimated national-security systems; Gartner's USD 857.5 billion forecast for banking and investment-services enterprise IT in 2026; and Everest Group's average USD 130–150 million PQC-readiness and early-migration estimate per top-50 financial-services enterprise through 2030. These references provide context, not independent validation of GVE's model. A detailed comparison is available on request.

Which manufacturers must an adopter contract with?

GVE’s model assumes zero to three, depending on the assessed provisioning route.

Platform keystores, hardware-backed keys and TPM 2.0 are reached through public APIs and need no bilateral agreement with a platform vendor; key-import and symmetric-key capabilities differ by device, operating-system version and API, and are checked per target rather than assumed. Only if provisioning at manufacture is chosen does an arrangement with secure-element makers or mobile operators become necessary, and there the supplier list is short and public. The central infrastructure that generates, distributes, updates, changes and revokes keys has already been built by GVE; an adopting institution implements the key operations that connect to it, not the platform itself.

How does PTI differ from conventional remote key onboarding?

Conventional remote onboarding commonly establishes trust through public-key cryptography when no secret is shared in advance. PTI changes that starting point: provision the first key securely, then protect later key delivery with existing symmetric keys. Device support for importing and protecting such keys varies by hardware, operating-system version and API, and is assessed for each deployment.

Standards and intellectual property

What is the standards position?

PTI's architecture follows ISO/IEC 24643:2020, published November 2020 and aligned in content with ECMA-417, which specifies an architecture for a distributed real-time access system: its function groups, their functionalities and their interfaces. The standard is technology-neutral. It does not specify PTI's key mechanics, does not address artificial intelligence or quantum computing, and does not certify GVE or any product; communication between function groups, and multi-layer functions such as security, are outside its scope. The properties on this page are GVE's design within that architecture.

What is the intellectual property position?

GVE Ltd. was incorporated in Tokyo in 2017. GVE reports its first patent application in December 2020 and a PCT application in December 2021, with protection expected in G7 markets except Canada through December 2040. Actual protection depends on granted claims, jurisdiction and maintenance. The subject matter is the provisioning and key-management mechanism; implementation details remain proprietary.

Where can the underlying material be obtained?

The one-page cost comparison and a technical note for institutions evaluating PTI in a specific setting — including deployments where autonomous agents transact within the domain — are available on request.

Selected sources

Primary references for the incident, cryptography, transition guidance and architecture. These sources do not evaluate GVE products.

• Hugging Face — technical timeline of the July 2026 agent intrusion (incident description used above) — https://huggingface.co/blog/agent-intrusion-technical-timeline
• NIST — Post-Quantum Cryptography FAQs (Grover's algorithm; continued use of AES) — https://csrc.nist.gov/projects/post-quantum-cryptography/faqs
• NIST IR 8547, Transition to Post-Quantum Cryptography Standards — initial public draft, November 2024 — https://csrc.nist.gov/pubs/ir/8547/ipd
• Ecma International — ECMA-417, Architecture for a distributed real-time access system (aligned with ISO/IEC 24643:2020) — https://ecma-international.org/publications-and-standards/standards/ecma-417/
• EU — coordinated PQC transition roadmap (risk-based milestones and symmetric alternatives) — https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography