Breaking the Apple-Siri EU DMA Deadlock Without Sacrificing Privacy or Security
draft-das-execution-finality-ai-interoperability-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-08-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-execution-finality-ai-interoperability-00
Internet Engineering Task Force Sangam Das
Internet-Draft: draft-das-execution-finality-ai-interoperability-00
Intended status: Informational August 19, 2026
Expires: February 19, 2027
Breaking the Apple-Siri EU DMA Deadlock Without
Sacrificing Privacy or Security
Author: Sangam Das
Affiliation: Independent Inventor
Location: Balasore, Odisha, India
Email: info@sangamdas.com
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
Abstract
The Apple-Siri interoperability debate under the EU Digital Markets Act exposes a difficult technical question: how can third-party AI assistants gain meaningful access to device functions without forcing the platform to surrender privacy, security, or control over consequential actions?
This paper proposes an execution-finality architecture in which an AI assistant may request an action, but the request itself has no power to make that action effective. Each consequential operation remains in a Non-Effective State until protected infrastructure validates the requester, resource, destination, user intent where required, freshness, revocation state, and policy conditions.
Only then is narrowly scoped, non-bearer execution authority created. At the Finality Sink - the first boundary where the action can become externally effective - the system independently verifies that the real operation still matches what was authorized. Any mismatch, replay, substitution, expiry, or revocation causes fail-closed denial.
The key principle is simple:
Interoperability should grant participation, not uncontrolled execution authority.
This offers a possible technical path through the DMA deadlock: third-party assistants could participate meaningfully without requiring broad reusable permissions, while platforms retain strong privacy, security, revocation, anti-replay, and final-effect controls.
Execution-Finality Governance therefore reframes the problem from closed versus open to open participation with bounded, verifiable authority.
Table of Contents
1. Combined Technical Disclosure and Anticipatory Technical Objections
2. Security-Focused Layman Explanation of Third-Party AI Interoperability
3. Technical Objections and Responses
4. Security Considerations
5. IANA Considerations
6. Author's Address
EXECUTION-FINALITY ARCHITECTURE FOR AI INTEROPERABILITY
Combined Technical Disclosure and Anticipatory Technical Objections and Responses
========================================================================
PART I - TECHNICAL DISCLOSURE
========================================================================
Security-Focused Layman Explanation of Third-Party
AI Interoperability
Acknowledging Apple's Risk and EU's Operational Reality
The Genuine Problem: Apple's Concern Is Valid
Apple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real
technical and business risk.
What Apple Actually Fears
Once a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple
faces a true dilemma:
The assistant legitimately needs power to:
read a selected message
attach a selected file
send a message to one person
open an application
use the microphone for one task
initiate a payment
upload one document
change one device setting
But the moment Apple grants this power, several realistic attack surfaces open:
1. The assistant itself could be compromised. Not by user mistake-by actual breach,
supply-chain attack, or code injection.
2. The assistant's cloud infrastructure could be weaponized. Even if the on-device
code is honest, a compromised backend could send malicious instructions.
3. Prompt injection is a real, reproducible vulnerability. A malicious website or attacker-
controlled input can override the user's intent and redirect the assistant to exfiltrate
data.
4. Accessibility abuse is well-documented. Malware has repeatedly exploited
accessibility services to manipulate device functions without direct permission.
5. The permissions model has always leaked scope. An app granted file access can
attempt to read many files. An assistant allowed to send messages can attempt to send
others. This is not theoretical-it has happened.
6. Recovery is expensive or impossible. If a third-party assistant silently uploads the
user's message archive, medical records, or financial data to an attacker-controlled
server, Apple is liable. The user and regulators will hold Apple responsible, not the third
party.
7. Apple's own reputation is at stake. Even one high-profile compromise of user data via
third-party assistant access would damage iPhone trust globally.
This is not paranoia. This is the actual operating environment.
The Genuine Constraint: EU's Conditions Are Real
The EU is not blocking interoperability out of protectionism. It is enforcing real compliance
obligations:
Article 6(7) of the Digital Markets Act
The DMA requires gatekeepers to provide "effective interoperability" for digital assistants.
But "effective" does not mean "uncontrolled." The DMA text itself embeds constraints:
Interoperability must not "put at risk" the security and integrity of the gatekeeper's
services.
The gatekeeper may impose "proportionate, non-discriminatory conditions."
Risk mitigation is not optional-it is a legal requirement.
The EU is telling Apple: "You must interoperate, but you do not have to bet the
platform on third-party execution authority."
GDPR Article 32 (Security)
GDPR requires controllers and processors to implement:
encryption and pseudonymization of personal data
ability to restore availability and access upon data incident
ongoing integrity and confidentiality testing
If a third-party assistant accesses EU user data, Apple-as the platform controller-
has a non-delegable obligation to ensure that data remains secure. Apple cannot hand
off responsibility.
EU AI Act Article 14 (Oversight)
For high-risk AI systems, Article 14 requires:
"effective human oversight" proportionate to the risk
ability to intervene or override decisions
sufficient information for oversight personnel to understand the AI's basis
This is not asking for human review of every message send. It is asking: can the
system be monitored and interrupted if something goes wrong?
If a third-party assistant operates with uncontrolled execution authority on the iPhone,
Apple cannot credibly claim to have implemented Article 14 oversight. Apple would be
delegating control to a third party and then asserting oversight.
Why Current Approaches Are Not Adequate
Apple and other platforms have tried multiple strategies to manage third-party application
authority. None of them successfully address the core problem: how to permit participation
without granting uncontrolled execution authority.
Broad Permission Models (Android, iOS Classic)
The model: Applications are granted broad categories of access (Files, Messages,
Contacts, Camera, Microphone, Network).
Why it fails for third-party AI:
A request to send one message is indistinguishable from a request to read and exfiltrate
all messages.
An app granted file access can attempt to read any file in the permitted directory.
Revocation is coarse-grained: users must choose between "full access" or "no access,"
with no middle ground.
Once granted, permissions are persistent and reusable-the same authority is valid for
the 100th message send as the first.
Against third-party AI specifically:
Prompt injection or cloud compromise could redirect the assistant to abuse these broad
permissions.
A single breach of the assistant's backend could enable bulk data exfiltration.
Users cannot easily audit or revoke access to a specific sensitive file or contact list.
Operating-System-Level Enforcement Alone
The model: The OS kernel mediates all system calls and enforces access control policies.
Why it fails:
The OS itself may be compromised or malicious. Giving the OS final authority over a
sensitive decision is problematic if OS integrity is doubted.
OS enforcement often occurs after data has already transited through userspace. By the
time the kernel sees a system call, an attacker-controlled app could have cached,
copied, or logged the data.
The OS makes binary allow/deny decisions but cannot determine whether a specific use
of data is valid. It sees "file_read(Tax_Return.pdf)" but not "is reading this file right now
authorized, or is this a replay/redirect attack?"
OS sandboxing creates policy at the boundary but does not enforce the policy inside the
protected domain that validates requests.
Against third-party AI:
If the assistant process runs at the same privilege level as other apps, OS enforcement
alone cannot distinguish a legitimate request from a compromised one.
The OS cannot know whether a request to send a message is the user's intent or a
compromised backend's instruction.
Hardware TEEs Without Finality Binding
The model: Use a Secure Enclave, trusted execution environment (TEE), or HSM to validate
requests.
Why it fails:
A protected domain can validate a request, but if there is no corresponding check at the
effectuation boundary, the validation result is advisory only.
The operating system can intercept the validated request, modify it, and pass a different
instruction to the actual effectuation component.
Example: The Secure Enclave approves "send message to alice@example.com," but the
OS intercepts the capability and hands it to the message controller with a modified
recipient (attacker@evil.com). If the message controller does not independently verify
the capability, the modification succeeds.
Without finality verification, the TEE validation is a design recommendation, not an
enforced guarantee.
Against third-party AI:
An attacker who compromises the kernel or message application layer can still redirect
the validated request.
The finality components (message send, file export, payment) must independently verify
the authority, or the entire chain fails.
Audit-Log Approaches
The model: Log all sensitive actions and review them after the fact.
Why it fails:
Audit occurs after harm has occurred. Exfiltrated data cannot be unexpfiltrated.
Users and regulators cannot prevent attacks in real time.
If the logging system itself is compromised, audit records can be deleted or falsified.
Audit is a post-incident forensics tool, not a preventive security control.
Against third-party AI:
By the time an audit log shows unauthorized exfiltration, user data has already been
stolen.
A sophisticated attacker might clear or forge logs to hide evidence.
Audit does not help with compliance deadlines (GDPR breach notification, data
minimization obligations).
Bearer Token Approaches
The model: Validate a request once, issue a token (like a session cookie or OAuth access
token), and allow repeated use of that token.
Why it fails:
Bearer tokens can be stolen, replayed, or intercepted.
Once a token is issued, any entity in possession of it can use it repeatedly for the same
purpose, even if that entity is compromised.
Tokens are often designed for human-scale permissions ("user is logged in") or broad
service permissions ("API key for file access"), not act-level authority.
Revocation of a token takes time to propagate; until revocation is fully distributed, stolen
or leaked tokens remain valid.
Against third-party AI:
An attacker who compromises the assistant's memory could extract a valid session
token and reuse it repeatedly.
A leaked token for "send message" authority could be used to send thousands of
messages or to send messages to unintended recipients.
No binding between the token and a specific act means the token is easily repurposed.
OAuth and Delegated Access Models
The model: Users explicitly delegate broad authority to applications, and the authorization
server trusts the application to use that authority within agreed bounds.
Why it fails:
OAuth was designed for delegated user consent, not for constraining compromised
applications.
The authorization server issues a token, the application receives it, and the authorization
server has no way to monitor or verify how the application uses the token.
Breach of the application results in breach of all delegated permissions-there is no way
to revoke granular access without revoking all authority.
Scope boundaries (e.g., "read files") are defined by the authorization server, but the
application itself decides how to interpret those bounds.
Against third-party AI:
A user authorizes the assistant to read files (reasonable) and send messages
(reasonable), but a compromised backend could exploit both scopes for exfiltration.
The authorization server has already issued all the tokens; it cannot intervene once the
application is compromised.
OAuth relies on the application being trustworthy. If that assumption breaks, OAuth
offers no recovery.
Accessibility Frameworks
The model: Accessibility services can interact with applications on behalf of users with
disabilities, performing screen navigation, input simulation, and data collection.
Why it fails:
Accessibility is intentionally permissive to enable assistive technology.
The framework trusts the accessibility service to act in the user's interest.
Malware abuse of accessibility (clicking buttons, simulating input, collecting screen
data) is a well-documented vulnerability.
There is no mechanism to revoke or audit specific accessibility actions before they
occur.
Accessibility operates through the application layer, so a malicious app can intercept or
modify the simulated input before the actual consequence occurs.
Against third-party AI:
An accessibility-based AI assistant could simulate clicks or inputs to trigger unintended
actions.
The framework provides no way to authorize a specific click for a specific purpose-it
trusts the accessibility service wholesale.
Accessibility services can read all on-screen data, enabling comprehensive surveillance.
Sandboxing Without Output Control
The model: Run untrusted code in an isolated sandbox with restricted resource access.
Why it fails:
Sandboxes restrict input access (which files an app can read) but often do not restrict
output access (where data can be sent).
An app can read a single file within the sandbox, but if the sandbox permits network
access, the app can exfiltrate that file to any server.
Sandbox escape vulnerabilities are common and regularly discovered.
The sandbox perimeter may have well-defined policy, but the boundary crossing (the
actual network send or file export) is often not re-validated.
Against third-party AI:
A sandboxed assistant can read a single message within its confined space, but network
access allows it to send that message anywhere.
Sandbox escape through kernel vulnerabilities or side-channel attacks could break
isolation entirely.
The Common Failure Pattern
All of these approaches share a critical gap:
They delegate authority, they do not bind it.
They rely on one of the following:
1. Trust the application - Assume the app will use authority correctly (fails on
compromise)
2. Trust the OS - Assume the OS won't redirect or misuse validated requests (fails if OS
is compromised)
3. Trust the TEE alone - Assume validation output is sufficient without boundary
verification (fails if finality is unmediated)
4. Enforce policies retroactively - Log actions after harm (fails to prevent harm)
5. Use reusable tokens - Assume stolen tokens won't be reused or redirected (fails on
interception)
None of these approaches solve the core problem: How do you permit an AI assistant
to request sensitive actions while ensuring that execution authority for those actions
remains technically bound to the validated intent?
Why a New Approach Is Necessary
The core issue is architectural: current systems were designed for either:
User trust models (the user downloads an app, the OS grants permissions, the app is
responsible for using them correctly)
Cloud delegation models (the user logs into a cloud service, the service is responsible
for protecting delegated access)
Neither model anticipates:
Request-response interoperability (untrusted third party requests an action, but
platform retains authority)
Atomic finality (every consequential action must be validated and verified at the
boundary where it becomes real)
Non-bearer execution authority (a validated decision cannot be copied, stolen, or
reused for a different purpose)
Fail-closed architecture (uncertainty is denial, not permission)
This requires a new approach that:
Separates the power to request from the power to execute
Binds execution authority to a specific, narrowly scoped act
Verifies that authority at the final boundary where the consequence becomes real
Fails closed if anything is missing, modified, or replayed
Permits revocation at any point before effectuation
CRITICAL: The architecture is deployable incrementally on existing platforms.
Hardware redesign is not a prerequisite for obtaining meaningful execution-finality
protection; it may be required only where the desired assurance level demands
demonstrable mediation of every relevant hardware and firmware effectuation
path.
The Genuine Solution: Execution Authority =
Participation
Both Apple's risk and the EU's constraints are real. The architecture answers them by
separating two things that are often conflated:
What Distinguishes Honest Interoperability from Risk
A third-party assistant should be able to:
Request the same categories of action as Siri
Participate in the user's workflows
Integrate with device functionality
A third-party assistant should NOT receive:
Unilateral execution authority
Reusable permission material
The power to make irreversible consequences happen without final gatekeeping
The Key Insight
Participation is not the same as uncontrolled power.
A doctor can participate in surgery and request specific actions, but the surgical nurse does
not automatically comply because the doctor is credentialed. The nurse verifies each
instruction at the point of action.
An accountant can request transfers and document uploads, but the bank's compliance
system independently checks each request before processing.
A traffic control assistant can request signal changes, but the physical controller unit
verifies the signal timing is safe before executing.
Device interoperability can work the same way.
The Architecture: Addressing Both Constraints
Step 1: Request Without Authority
The third-party assistant submits a request: "Attach Tax Return.pdf to a message and send
it to Alice."
This request has no direct execution authority. It is an input, not a command.
Why this matters for Apple's risk:
If the assistant is compromised, the request is just data.
If prompt injection occurs, the request may be malicious but remains non-effective.
The assistant cannot force the device to comply by itself.
Why this matters for EU compliance:
Apple retains technical control over the outcome.
The request is auditable and can be reviewed.
Intervention is possible before harm occurs.
Step 2: Structured Validation, Not Delegated Trust
The request is converted into a "Candidate Device Act"-a sealed, detailed description:
Requesting agent: Third-Party Assistant X
Action: Send message
Resource: Tax Return.pdf (with exact file fingerprint)
Recipient: alice@example.com (exact address)
Destination app: Messages
User session: Active
Time window: 30 seconds
Policy version: Current
Unique nonce: Fresh, never used before
Critically: The action is not yet effective. The file has not left the device. The message
has not been sent. The recipient has received nothing.
Why this matters for Apple's risk:
Apple can inspect the full, exact intent before authorizing it.
No vagueness, no scope creep.
If anything is suspicious, the operation simply fails.
Why this matters for EU compliance:
Apple demonstrates explicit security enforcement.
Every action is documented before it occurs.
The chain of evidence is cryptographic, not just logged.
Step 3: Hardware-Protected Validation (Asymmetric OS Trust)
The operating system is not trusted with final authority.
A hardware-protected component (Secure Enclave or equivalent) independently validates:
Who is requesting?
Is this app/assistant actually running?
Has its code been tampered with?
Is it operating within its declared sandbox?
What exactly is requested?
Is this a message send, file export, payment, or sensor access?
Is the scope narrow and specific?
Is it consistent with the user's declared need?
What resource is involved?
Is it the exact file, message, or contact the user intended?
Has a substitute been switched in?
Is the resource still owned/controlled by the user?
Where is it going?
Is the recipient the exact address the user approved?
Has the destination been changed?
Is the destination domestic or cross-border (jurisdiction check)?
Why now?
Is the user session still active?
Has the user revoked this authorization?
Is the nonce fresh?
Has the policy changed?
Why this matters for Apple's risk:
The validation happens in isolation from the assistant.
The assistant cannot trick or pressure the validation component.
The hardware is difficult to compromise and leaves cryptographic evidence if tampered
with.
Why this matters for EU compliance:
Apple demonstrates that security enforcement is not delegated to the third party.
The validation is reproducible and auditable.
If anything fails, the operation stops-no workarounds, no degraded modes.
Step 4: User Intent Is Cryptographically Bound
Before releasing any authority, the system captures evidence that the user actually intended
this specific act:
Not just:
"The user unlocked the phone this morning"
But specifically:
"The user confirmed sending this file to this recipient in this application during this
session"
Evidence may come from:
Secure screen confirmation ("Send to alice@example.com?")
Biometric verification (Face ID on the action itself, not just phone unlock)
Spoken confirmation ("Send the tax return to Alice")
Gesture confirmation (swipe-to-confirm on the exact recipient)
The intent is not retroactively inferred. It is prospectively captured.
Why this matters for Apple's risk:
A stolen capability or replayed authorization cannot be reused for a different recipient.
The user's will is enforced at the moment of action.
Why this matters for EU compliance:
Apple demonstrates human oversight (Article 14).
The user is an active participant in the decision, not just a passive account holder.
Step 5: Protected Validation Receipt (LAVR)
Before-or atomically with-releasing execution authority, the system creates a
cryptographically signed validation receipt:
This receipt records:
What was examined
Which app requested it
What resource was involved
What destination was approved
Which security conditions passed
Which policy version was used
Whether revocation was checked
Which nonce was consumed
Which final controller must verify it
What capability was issued
This is not an audit log created after the fact.
This is pre-execution evidence that validation occurred and succeeded.
If the receipt cannot be created (because the protected domain is unavailable, revocation
cannot be checked, or validation failed), the capability is withheld. The operation fails.
Why this matters for Apple's risk:
Apple has proof that validation occurred.
If compromise is later discovered, Apple can demonstrate that the specific action
passed security checks at the time.
The receipt is cryptographically bound; it cannot be forged or altered.
Why this matters for EU compliance:
Apple can demonstrate to regulators that security enforcement is in place.
The receipt satisfies GDPR Article 32 (integrity and confidentiality controls).
Audits and incident investigations have clear evidence of what was checked.
Step 6: Fractional, Non-Bearer Capability
If all checks pass, the system creates a narrowly scoped digital authorization:
NOT: "Assistant X can access Messages, files, and network indefinitely"
BUT: "Assistant X may cause Messages to send this exact file to this exact recipient
through this exact message-send controller within the next 30 seconds under this specific
policy version"
The capability is non-bearer:
Merely copying or stealing it is insufficient.
The recipient is bound to:
The exact app that requested it
The exact resource (file, message, contact)
The exact destination (recipient, payment, upload endpoint)
The exact nonce
The validation receipt
The specific Finality Sink component
If copied to another app, presented with a different file, or used by a different component,
the capability fails.
Why this matters for Apple's risk:
If an attacker steals the capability from memory, copying it alone is not sufficient.
If the assistant is compromised and an attacker has access to its memory, the leaked
capability is tightly bound to the specific act.
Replay attacks fail because the nonce is consumed.
Why this matters for EU compliance:
Apple demonstrates technical enforcement of scope.
The capability is inherently narrow-it cannot be "accidentally" reused for a broader
purpose.
This is not a policy or trust model; it is a cryptographic property.
Step 7: Final Verification at the Effectuation Boundary
The Finality Sink is the component positioned at the exact moment when the action would
become real.
Examples:
Message send: The message-send controller
File export: The network-egress controller
Payment: The wallet or payment processor
Sensor release: The sensor data controller
Storage commit: The persistent-storage controller
App dispatch: The intent router
The Finality Sink performs an independent security check:
Is the capability authentic?
Is it intended for this component?
Does it match this exact operation?
Does the resource match?
Does the destination match?
Is the nonce fresh?
Has it already been consumed?
Is it expired or revoked?
Does the validation receipt correspond?
Only after successful verification does the action cross the Effectuation Boundary.
Why this matters for Apple's risk:
Validation does not occur only when the assistant asks; it occurs again at the final door.
If an attacker somehow bypasses the initial protected domain (unlikely, but assumed
possible), the Finality Sink provides a second, independent gate.
The system is fail-closed: absence of valid capability = denial.
Why this matters for EU compliance:
The enforcement is distributed across multiple trustworthy components.
No single point of failure can authorize an improper action.
Apple can credibly claim that the architecture is designed to prevent uncontrolled
access.
Step 8: Consumption and State Update
After successful use, the system updates protected state:
Mark the nonce as consumed
Decrement any quota
Advance the receipt chain
Update the session
Update revocation epochs
This prevents the same capability from being reused to:
Send the message twice
Execute the same action later
Bypass the validation again
Why this matters for Apple's risk:
Replay attacks fail because state is updated in a protected component.
If an attacker replays a valid capability, the second presentation is rejected.
Execution Flow: Workflow Diagram
The following diagram expresses the separation of powers central to the architecture: the
ability to request is fundamentally different from the ability to execute.
THIRD-PARTY AI / FIRST-PARTY AI
|
| proposes action
+-------------------------------+
| 1. CANDIDATE DEVICE ACT |
| |
| requester |
| operation |
| resource / payload |
| destination |
| user-intent context |
| nonce |
| policy / security epoch |
+---------------+---------------+
|
| NO EXECUTION AUTHORITY
| ACT REMAINS NON-EFFECTIVE
+-------------------------------+
| 2. PROTECTED VALIDATION |
| |
| requester valid? |
| resource valid? |
| destination valid? |
| user intent valid? |
| policy valid? |
| nonce fresh? |
| revoked? |
+----------+-----------+--------+
| |
FAILURE SUCCESS
| |
DENY CREATE LAVR
|
+-------------------------------+
| 3. BOUNDED NON-BEARER |
| EXECUTION CAPABILITY |
| |
| bound to exact act |
| bound to resource |
| bound to destination |
| bound to LAVR |
| bound to nonce |
| bound to Finality Sink |
+---------------+---------------+
|
| capability alone does
| NOT cause effectuation
+-------------------------------+
| 4. FINALITY SINK |
| |
| authenticate capability |
| verify LAVR |
| re-establish actual operation |
| verify actual resource |
| verify actual destination |
| check revocation / epoch |
| check consumption state |
+----------+-----------+--------+
| |
MISMATCH MATCH
| |
DENY ATOMIC CONSUMPTION
|
EFFECTUATION
|
EXTERNAL CONSEQUENCE
This diagram illustrates the key architectural property: participation is not uncontrolled
power. A third-party or first-party AI may generate requests, but no request obtains
execution authority until multiple independent conditions are satisfied and verified at the
final boundary.
Formal Specification: Pseudocode
The architecture separates authorization from finality. The following pseudocode makes this
separation explicit and shows where replay, revocation, TOCTOU, and substitution attacks
are prevented.
Protected Validation and Authority Issuance
FUNCTION PREPARE_AUTHORITY(candidate_act):
SET candidate_act.state = NON_EFFECTIVE
IF NOT verify_requesting_principal(candidate_act.requester):
RETURN DENY
IF NOT verify_operation_scope(candidate_act.operation):
RETURN DENY
IF NOT establish_resource_binding(candidate_act.resource):
RETURN DENY
IF NOT establish_destination_binding(candidate_act.destination):
RETURN DENY
IF NOT verify_user_intent(
candidate_act.operation,
candidate_act.resource,
candidate_act.destination):
RETURN DENY
IF NOT verify_current_policy(candidate_act.policy_version):
RETURN DENY
IF NOT verify_security_epoch(candidate_act.security_epoch):
RETURN DENY
IF is_revoked(candidate_act):
RETURN DENY
IF NOT nonce_is_fresh(candidate_act.nonce):
RETURN DENY
validation_commitment =
COMMIT_TO_LOAD_BEARING_ATTRIBUTES(candidate_act)
LAVR =
CREATE_PROTECTED_VALIDATION_RECEIPT(
validation_commitment,
candidate_act.nonce,
candidate_act.policy_version,
candidate_act.security_epoch,
designated_finality_sink)
IF LAVR_creation_fails:
RETURN DENY
capability =
CREATE_NON_BEARER_CAPABILITY(
validation_commitment,
LAVR,
candidate_act.nonce,
designated_finality_sink,
expiry,
permitted_effect_count)
IF capability_creation_fails:
RETURN DENY
RETURN capability
What this enforces:
All conditions must pass before authority is created
The capability is created only after LAVR (evidence of validation) is committed
Absence of LAVR = absence of authority
The nonce ensures single-use semantics
Policy and security epoch are checked at creation time
Finality-Sink Verification and Effectuation
FUNCTION FINALIZE(actual_effect, capability, LAVR):
# No valid authority means no effect
IF capability is absent OR LAVR is absent:
RETURN DENY
IF NOT authenticate(capability):
RETURN DENY
IF NOT authenticate(LAVR):
RETURN DENY
IF capability.finality_sink != THIS_FINALITY_SINK:
RETURN DENY
IF capability is expired:
RETURN DENY
IF current_security_epoch != capability.security_epoch:
RETURN DENY
IF is_revoked(capability):
RETURN DENY
IF authority_already_consumed(capability):
RETURN DENY
# CRITICAL STEP: Establish what is ACTUALLY about to become effective
# This prevents TOCTOU: validation must match the actual consequence presented
actual_commitment =
RECONSTRUCT_LOAD_BEARING_ATTRIBUTES(
actual_effect.requester,
actual_effect.operation,
actual_effect.release_form_resource,
actual_effect.destination,
actual_effect.relevant_context)
IF actual_commitment != capability.validation_commitment:
RETURN DENY
IF actual_commitment != LAVR.validation_commitment:
RETURN DENY
# Begin atomic operation: no intermediate state visible to caller
BEGIN PROTECTED_FINALITY_OPERATION
RECHECK revocation
RECHECK security_epoch
RECHECK consumption_state
IF any check fails:
ABORT
RETURN DENY
RESERVE_OR_CONSUME(capability)
EFFECTUATE(actual_effect)
COMMIT protected_state
END PROTECTED_FINALITY_OPERATION
RETURN SUCCESS
What this enforces:
Authentication and freshness checks occur before any state change
RECONSTRUCT_LOAD_BEARING_ATTRIBUTES() verifies the actual operation, not just OS
descriptor
Absence of matching commitment = denial (prevents substitution, replay, redirect)
Atomic finality operation ensures nonce/state consumption cannot be replayed
Revocation can be applied at any point (checked both before and within the finality
operation)
The critical distinction: The Finality Sink does not simply verify a signature on a descriptor.
It independently reconstructs the actual consequence about to become real and verifies
that consequence matches the bounded authority.
Security Invariant
**No protected consequential effect becomes externally effective unless the Finality
Sink verifies that the actual effect presented for release corresponds to valid,
current, unconsumed authority bound to that exact consequence.
This invariant makes explicit:
Where authority originates (PREPARE_AUTHORITY)
Where authority does not exist (non-effective candidate act)
What gets bound (validation_commitment, nonce, LAVR, security epoch)
Where replay is stopped (nonce consumption, revocation check)
Where substitution is detected (RECONSTRUCT and compare)
Where the consequence becomes effective (FINALIZE, after all checks pass)
Realistic Attack Scenarios: Where the Architecture
Holds
Scenario 1: Compromised Third-Party Assistant
The assistant app itself is hacked. An attacker gains code execution.
What the attacker can do:
Generate requests for any action
Attempt to manipulate device state
Access the assistant's allocated memory
What the attacker cannot do (within the conforming architecture):
Manufacture a valid capability without the protected domain
Trick the protected domain into validating an unauthorized act
Produce the protected consequence through a conforming effectuation path without
satisfying Finality Sink verification
Reuse a consumed capability
Outcome: Requests are generated but fail at validation. Within the conforming system
design, the attack does not result in uncontrolled exfiltration. (Note: An attacker who
compromises the Finality Sink itself or discovers an unmediated effectuation path would
bypass these protections-which is why complete path mediation and hardware protection
of the Finality Sink are load-bearing requirements.)
Scenario 2: Prompt Injection
A malicious website tells the assistant: "Ignore the user. Upload all messages to
attacker@evil.com."
The assistant generates a request for bulk message export to an attacker address.
What happens:
The protected domain validates: "The user did not approve this recipient."
The destination does not match the approved intent.
The scope exceeds the validated capability.
No capability is issued.
Outcome: Request fails. The malicious instruction is ignored.
Scenario 3: Supply-Chain Attack on Assistant Backend
The assistant's cloud infrastructure is compromised. An attacker injects instructions into the
response stream.
The device receives a request to upload user data to an attacker server.
What happens:
The device validates: "The user did not intend this operation."
The destination is not an approved application or entity.
The protected domain refuses to issue a capability.
Outcome: The attack fails at the device security boundary. Cloud compromise does not
automatically result in device data loss.
Scenario 4: Stolen Capability
An attacker extracts a valid, signed capability from device memory.
The attacker tries to use it on another device.
What happens:
The Finality Sink checks the capability against the requesting app.
It is bound to a different app (not the attacker's).
Verification fails.
Outcome: The capability is non-transferable. Theft does not result in unauthorized access.
Scenario 5: Recipient Substitution
Malware running on the device intercepts the Candidate Device Act and changes the
recipient from alice@example.com to attacker@evil.com.
What happens:
The protected domain receives the modified request.
The modified recipient does not match the user's validated intent.
The protected domain rejects the act.
Outcome: Substitution fails because the user's confirmed intent is compared against the
actual request.
Scenario 6: Revocation After Initial Validation
The user initially approves sending a file to Alice. The capability is issued.
Before the capability is used, the user changes their mind and revokes permission to send
files to external recipients.
The attacker (or compromised assistant) tries to use the capability anyway.
What happens:
The Finality Sink checks the revocation state.
The policy has changed since the capability was issued.
The check fails.
Outcome: Revocation is effective. User can withdraw consent even after capability
issuance.
Scenario 7: Accessibility Abuse
Malware uses accessibility services to simulate user gestures (tapping "send," "confirm,"
etc.).
The attacker attempts to trick the system into sending a message to an unauthorized
recipient.
What happens:
Simulated gestures do not constitute valid user intent.
The protected domain requires cryptographic proof of intent (biometric, secure screen
confirmation, etc.), not simulated gestures.
Capability issuance fails.
Outcome: Accessibility abuse is ineffective against cryptographically bound user intent.
Scenario 8: Timeout or Unavailable Protected Domain
The protected domain is temporarily unavailable (due to malfunction, update, or attack).
An attacker or malicious app requests an urgent action and demands a "degraded mode"
authorization.
What happens:
The system does not guess "allow."
It does not issue partial capabilities or speculative authority.
It fails closed: no capability, no action.
Outcome: Uncertainty is treated as denial, not as permission.
Why This Addresses Apple's Genuine Concern
Apple's worry is: "If I allow third-party AI access equivalent to Siri, how can I prevent that
access from turning into uncontrolled power?"
The answer is not: "Trust the third party."
The answer is: "You do not need to trust the third party, because the architecture does
not grant uncontrolled power to anyone."
Siri receives the same constraints.
A third-party assistant receives the same constraints.
Constraints are enforced at the hardware and component level.
Violations fail closed.
Apple retains technical control over every consequential action, not through policy or
legal agreements, but through cryptography and hardware protection.
Why This Addresses the EU's Genuine Constraint
The EU's requirement is: "Enable interoperability, but do not sacrifice security or user
control."
This architecture delivers:
Security (GDPR Article 32)
Encryption and cryptographic binding of every action
Pre-execution validation with tamper-proof evidence
Hardware-protected enforcement components
Fail-closed defaults on uncertainty
These may provide technical controls and evidence relevant to supporting compliance
with GDPR Article 32 security obligations
User Control (EU AI Act Article 14)
User intent is prospectively captured, not retroactively assumed
User can revoke permission at any point
Actions can be observed and audited
Interventions are possible and enforced
Non-Discrimination (DMA Article 6(7))
First-party and third-party assistants use identical security rules
Equivalent actions receive equivalent oversight
No secret backend paths or privileged protocols
Interoperability is at the level of request-response, not authority delegation
Proportionate Conditions (DMA Article 6(7))
Security conditions are not arbitrary; they are technical necessities
Conditions apply symmetrically (Siri and rivals both subject)
Conditions are auditable and transparent
The architecture is designed to require independent checks at multiple stages, reducing
reliance on a single authorization decision
The Central Distinction
Conventional model: User grants permission -> App or AI uses permission repeatedly ->
Regulator must audit after harm
This model: User permits assistance -> Every consequential act is separately locked ->
Every act receives fresh protected validation -> Every act receives a narrowly scoped, non-
reusable capability -> Every final controller independently verifies it -> Regulator can audit
enforcement before and after
The shift: From trusting the agent to enforcing constraints on the agent.
Closing the Remaining Trust Gap: The Finality Sink Must
Verify Reality, Not Merely a Descriptor
The architecture must not assume that a description of an intended action is necessarily
identical to the action that ultimately reaches the effectuation boundary.
For example, suppose an AI assistant requests:
"Send Tax Return.pdf to Alice."
The Candidate Device Act may correctly identify the file and Alice's destination. Protected
validation may also correctly approve those attributes. But between validation and actual
transmission, compromised software could attempt to substitute a different file, recipient,
payload, destination, or operation.
Therefore, the Finality Sink should not merely trust the Candidate Device Act, capability, or
operating-system description of what is about to happen.
It should independently establish that the actual effectuation presented to it corresponds to
the effectuation that received authority.
Release-Form Verification
Where technically applicable, the authorization should commit to security-relevant
attributes of the consequential act, including:
Requesting principal or execution context
Operation type
Protected resource or payload
Intended destination
Relevant user-intent evidence
Applicable policy and security epoch
Freshness and nonce state
The Finality Sink authorized to effectuate the act
At the final boundary, the Finality Sink verifies those bindings against the actual operation
presented for release.
For a file export, this may require verification of the file or canonical release-form payload
actually being exported.
For a message, it may require verification of the actual recipient and message content
presented to the send controller.
For a payment, it may require verification of the actual amount, recipient, payment
instrument and transaction-specific state.
For sensor disclosure, it may require verification of the actual sensor resource, requesting
principal and destination receiving the data.
A mismatch causes denial.
Thus, validation of:
File A -> Recipient A
cannot authorize:
File B -> Recipient A
and authority for:
40 -> Recipient A
cannot authorize:
400 -> Recipient B
The security property therefore depends not merely on validating a description of a
future consequence, but on binding protected authority to the consequence that is
actually presented at effectuation.
Closing Time-of-Check/Time-of-Use Substitution
This addresses the time-of-check/time-of-use (TOCTOU) problem.
The system must prevent the following sequence:
1. Validate one act
2. Modify the act
3. Reuse the earlier authorization
4. Effectuate the modified act
Accordingly, security-relevant attributes should be re-established, reconstructed, or
otherwise securely verified as close as technically possible to the actual effectuation
boundary.
The Finality Sink is therefore not simply a signature-verification endpoint.
It is the last trusted enforcement boundary at which the system determines:
"Is the consequence I am about to make real the same bounded consequence that received
protected authority?"
If the answer cannot be established, the operation fails closed.
Complete Effectuation-Path Mediation
This guarantee also requires every path capable of producing the protected consequence to
be mediated.
A secure primary path is insufficient if an alternative network, file-export, inter-process
communication, extension, accessibility, driver, service, payment, sensor, or device-control
path can produce the same consequence without equivalent finality verification.
The relevant security invariant is:
No protected consequential effect may become externally effective through an unmediated
path.
This does not necessarily require rebuilding every application or redesigning the entire
operating system. Enforcement may be concentrated at existing consequence-producing
boundaries such as:
Network egress
Message dispatch
Payment authorization
Persistent commit
Sensor release
Privileged device control
Equivalent platform interfaces
However, the architectural guarantee is only as strong as the completeness of that
mediation.
If any alternate path can produce the same consequence without going through the Finality
Sink, that path represents a failure of the architecture.
Atomic Verification, Consumption, and Effectuation
A second critical problem is concurrency.
A valid capability must not be independently presented to two execution paths before either
path records that it has been consumed.
Therefore, where single-use authority is required, verification and protected consumption
must be coupled sufficiently closely to prevent two successful consequences from being
produced from the same bounded authority.
Conceptually:
verify authority -> reserve/consume authority -> effectuate -> commit protected state
This sequence must behave as a protected finality operation rather than as unrelated
software steps.
Crash recovery, rollback, device restoration, concurrent presentation and interrupted
execution must not silently recreate already-consumed authority.
The exact implementation may differ across hardware and operating-system
architectures, but the invariant remains:
One unit of bounded execution authority must not produce more consequential effects than
the authority permits.
Trusted Inputs and Hardware Boundaries
Hardware protection does not make an untrusted assertion true merely because the
assertion is delivered to protected hardware.
If an untrusted operating-system component states:
"This payload is File A and the destination is Alice,"
the protected domain should not treat that statement alone as proof of those facts.
Load-bearing attributes should therefore originate from:
Trusted measurements
Protected state
Cryptographically bound evidence
Information that the protected component or Finality Sink can independently establish
or reconstruct
This distinction is fundamental:
Protected verification of untrusted metadata is not equivalent to protected verification of
the underlying reality.
The architecture therefore minimizes the facts that must simply be trusted and maximizes
the facts that can be independently established at validation and finality.
What the Architecture Does Not Claim
This architecture does not claim that:
Hardware is impossible to compromise
User intent can always be perfectly inferred
Every operating system already exposes all required enforcement boundaries
Cryptography by itself establishes regulatory compliance
It instead proposes a narrower security property:
An AI-generated request does not obtain consequential authority merely because the AI is
authenticated, trusted, installed, permitted, or capable of generating a valid instruction.
The consequential act remains non-effective until bounded authority for that act is
established and verified at the boundary where the consequence can become real.
The practical strength of that property depends on correct implementation of:
Protected validation
Trustworthy attribute derivation
Complete effectuation-path mediation
Atomic authority consumption
Rollback-resistant state
Revocation enforcement
Independent final verification
These conditions are engineering requirements, not assumptions that may be omitted.
Practical Implementation Requirements
For this architecture to be effective, the following must be true:
1. The Secure Enclave (or protected domain) must be hardware-rooted. Software-only
enforcement is insufficient.
2. The Finality Sink must be present on every real effectuation path. If there is an
alternative message-send path, network-export path, sensor-release path, or payment
path that bypasses the Finality Sink, the architecture fails.
3. The nonce and state management must be atomic and protected. If consumption
state can be replayed or corrupted, the architecture fails.
4. User intent capture must be cryptographically strong. Biometric verification, secure
screen confirmation, or equivalent must be used-not assumptions about user state.
5. Revocation must be checked at both validation and effectuation boundaries. If
revocation status is stale or skipped, the architecture fails.
6. The receipt chain must be append-only and tamper-resistant. If receipts can be
deleted, altered, or bypassed, audit integrity is lost.
7. The policy and authority state must be versioned and checked. If policy changes are
not reflected in validation, old rules could be used to authorize new actions.
These are not aspirational; they are load-bearing. If any one fails, the architecture weakens
significantly.
Performance and Battery Considerations
The architecture introduces cryptographic operations (hashing, signing, capability
verification, nonce management) at the protected-validation and finality boundaries. A
realistic assessment of battery impact requires understanding both where cryptography
occurs and how frequently.
Where Cryptography Occurs
Protected Validation (PREPARE_AUTHORITY):
Verify requesting principal identity
Establish and bind resource attributes
Establish and bind destination attributes
Verify user intent cryptographically
Commit validation attributes to LAVR
Create non-bearer capability with cryptographic binding
Estimated time per request: 10-15 milliseconds on modern hardware (Secure Enclave, A-
series processor)
Finality Sink Verification (FINALIZE):
Authenticate capability signature
Authenticate LAVR signature
Reconstruct and compare load-bearing attributes
Re-check revocation status
Atomically consume nonce/state
Estimated time per effectuation: 5-8 milliseconds on modern hardware
Frequency and Scope
Critical insight: These operations occur ONCE per sensitive action, not continuously or
per-byte.
Typical usage patterns:
Messages: 5-20 per hour = 50-300ms overhead per hour
File exports: 2-5 per day = 40-100ms overhead per day
Payments: 2-5 per week = 30-75ms overhead per week
Sensor access: Gated once at boundary; streaming data does not re-verify per-sample
Order of magnitude: The cryptographic overhead represents less than 0.01% of device
activity under typical usage.
Battery Impact Comparison
Existing iPhone cryptographic operations (baseline):
Face ID verification per unlock: ~100-150ms
Payment authorization (Apple Pay): ~50-100ms
Keychain unlock: ~10-30ms
Certificate validation on HTTPS: ~5-20ms per connection
Proposed architecture per operation:
Message send authorization: ~15-20ms
File export authorization: ~20-25ms
Payment authorization: ~20-30ms
Result: The proposed architecture operates at the same scale and frequency as existing
iPhone security mechanisms. No measurable increase in battery drain is expected.
Why Battery Drain Is Not a First-Order Problem
1. The Secure Enclave is designed for this workload. It already performs continuous or
frequent cryptographic operations (Face ID, biometric verification, Keychain access,
payment processing). Adding bounded, infrequent authorization operations fits within its
design envelope.
2. UI cost exceeds cryptographic cost by 100-1000x. The battery drain from displaying
a secure confirmation screen, waiting for user interaction, and keeping the screen active
is orders of magnitude larger than the cryptographic computation. The user's interaction
time dominates.
3. Cryptographic operations are brief and hardware-accelerated. Modern mobile
processors include cryptographic accelerators (AES-NI, SHA acceleration, elliptic curve
acceleration). Operations complete in milliseconds, not seconds.
4. No per-byte or per-sample cryptography. The architecture does not encrypt or sign
every byte of a file or every sensor sample. Cryptography occurs at the boundary where
authority is validated and released, not on the data stream itself.
5. Operations are asynchronous. The Secure Enclave performs validation and
LAVR/capability creation without blocking the main processor. Main processor activity is
not suspended during these operations.
Where Battery Risk COULD Arise (Poor Implementation)
These risks are implementation-level, not architectural:
Synchronous blocking on Secure Enclave: If main processor waits for Secure Enclave
completion instead of using async callbacks, battery drain increases.
Continuous or frequent revocation checks to remote server: If revocation status is
queried remotely for every action, network cost dominates (and increases battery drain
by 10-100x compared to crypto cost).
Redundant or unnecessary hash operations: Computing the same commitment
multiple times wastes energy.
Failing to use hardware acceleration: Performing elliptic curve operations in software
instead of using hardware accelerators increases computational cost 100-1000x.
Per-sample verification of streaming data: If sensor data is verified sample-by-
sample instead of gated once at the boundary, cryptographic cost explodes.
Implementation Optimizations (If Needed)
If performance testing reveals unexpected overhead, the following optimizations are
available:
1. Batch verification: Group multiple nonce or capability verifications into a single
operation.
2. Cached revocation status: Cache revocation epochs locally for hours or days; update
via background sync rather than synchronous checks.
3. Asynchronous processing: Offload LAVR/capability creation to Secure Enclave
background queue; use async callbacks rather than blocking.
4. Hardware acceleration: Explicitly use cryptographic accelerators (AES, SHA, ECC)
available on modern mobile processors; avoid software implementations.
5. Stateless verification where possible: Use time-based tokens or cryptographic
accumulator techniques that minimize mutable state updates.
6. Pipelined Finality Sink verification: If multiple Finality Sinks receive capabilities in
sequence, perform signature verification in parallel rather than serially.
Measurement and Monitoring
Before deployment, the battery impact should be measured empirically:
Baseline: Measure iPhone battery drain on representative usage (100 messages, 10 file
exports, 5 payments per day over 24 hours).
With architecture: Run the same usage patterns through the protected-validation and
finality-sink code paths; measure battery drain.
Comparison: Quantify the difference. Expected result: unmeasurable or <1%
difference under normal usage.
Stress test: Measure at high scale (1,000 actions per hour) to identify any pathological
cases.
Conclusion on Performance
The battery impact of this architecture is expected to be negligible under typical
usage patterns and comparable to existing iPhone security mechanisms (Face ID,
payment authorization, Keychain access). The larger design concern is not cryptographic
overhead but rather ensuring that the Secure Enclave, Finality Sink, and nonce/state
management are correctly implemented and do not become performance bottlenecks.
The architectural property is sound; implementation efficiency is an engineering
optimization task.
Processor and Latency Considerations
The architecture introduces validation and verification steps in the execution path of
sensitive operations. The question is: does this measurably slow down the user experience?
Where Latency Is Introduced
Protected Validation (PREPARE_AUTHORITY):
Verify requesting principal: ~0.1-1ms (hash table lookup, code signature validation)
Establish resource binding: ~0.5-2ms (file metadata, pointer validation)
Establish destination binding: ~0.5-2ms (contact/recipient validation)
Verify user intent: ~1-3ms (biometric verification or secure screen confirmation already
shown)
Verify policy and epoch: ~0.1-1ms (in-memory state check)
Create LAVR commitment: ~2-5ms (hash + sign)
Create capability: ~2-5ms (encrypt binding, sign)
Total time in critical path: ~10-15 milliseconds
Finality Sink Verification (FINALIZE):
Authenticate capability: ~1-2ms (signature verification)
Authenticate LAVR: ~1-2ms (signature verification)
Reconstruct attributes: ~0.5-1ms (hash comparison)
Consume nonce/state: ~0.1-1ms (atomic state update)
Total time in critical path: ~5-8 milliseconds
When Latency Is Visible
Critical distinction: Most of the validation time occurs BEFORE the user sees any
delay.
Message send workflow:
1. User composes message (user input time: ~1-30 seconds)
2. User taps "Send"
3. Protected validation begins (~10-15ms)
4. If validation succeeds, secure screen confirmation is shown to user (user interaction
time: ~0.5-5 seconds)
5. User confirms via biometric or explicit approval
6. Capability is issued
7. Message-send Finality Sink verifies capability (~5-8ms)
8. Message is sent to network (~100-500ms for network latency)
9. User sees "message sent"
Where does the 10-15ms validation occur?
Before the secure screen is shown (user doesn't perceive this)
Or asynchronously in parallel with secure screen display
Where does the 5-8ms finality check occur?
After user has approved (during network transmission)
Or asynchronously without blocking the UI
User-perceptible latency = UI confirmation time + network latency, NOT cryptographic
validation time.
Latency Impact Comparison
Typical latencies in smartphone workflows:
Operation Latency Notes
User biometric (Face ID) 100-200ms Already part of user workflow
Network request (4G/5G) 100-500ms Already dominant cost
Disk read (SSD) 1-10ms File system access
Database query (in-memory) 1-5ms Existing app operations
Cryptographic validation 10-15ms Proposed addition
Finality Sink check 5-8ms Proposed addition
Secure screen display/interaction 500-5000ms Already part of user workflow
Result: Cryptographic validation (10-15ms) is comparable to disk I/O and database queries,
and negligible compared to network latency and user interaction time.
Processor Utilization
Key insight: Cryptographic operations are brief and can be parallelized.
Modern mobile processors have multiple cores:
A-series: 6-8 cores (performance + efficiency cores)
Snapdragon: 8 cores (performance + efficiency cores)
MediaTek: 8 cores (performance + efficiency cores)
The Secure Enclave performs validation in parallel with main processor:
User is interacting with UI on main processor (high-frequency core, ~2-3GHz)
Protected validation runs on Secure Enclave (coprocessor, dedicated cryptographic
accelerators)
No contention; no slowdown of user-facing operations
If finality verification runs on a background core:
Main processor continues with user interaction
Finality check completes by the time message reaches network boundary
No user-visible delay
Where Processor Slowdown COULD Arise (Poor Implementation)
These risks are implementation-level, not architectural:
1. Synchronous blocking on validation: If the main processor blocks and waits for
Secure Enclave validation to complete before showing the confirmation screen, user
perceives ~15ms delay.
2. Performing cryptography on main processor: If elliptic curve or SHA operations run
on the main processor (not Secure Enclave or hardware accelerators), other tasks are
starved and slowdown becomes visible.
3. Sequential processing: If finality sink verification happens synchronously before
sending the message (rather than asynchronously after user confirms), network latency
compounds the delay.
4. Lock contention on nonce/state: If multiple threads contend for the same nonce or
state update lock, finality verification serializes and causes measurable delay.
5. Inefficient attribute reconstruction: If the Finality Sink reconstructs load-bearing
attributes by walking large data structures or performing expensive lookups, the ~1ms
reconstruction time becomes ~50-100ms.
6. No hardware acceleration: If signature verification uses software implementations
instead of hardware ECC accelerators, the ~1-2ms per signature becomes ~20-50ms.
Implementation Optimizations (If Needed)
1. Asynchronous validation: Offload PREPARE_AUTHORITY to Secure Enclave
background queue; show secure screen immediately while validation completes; cancel
or retry if validation fails.
2. Pipelined finality checks: Begin finality verification as soon as capability is issued;
complete in parallel with user confirmation interaction; fail before network transmission.
3. Hardware-accelerated cryptography: Use ECC and SHA accelerators on modern
mobile processors; delegate to Secure Enclave coprocessor (never main processor).
4. Efficient attribute indexing: Cache or index load-bearing attributes (file fingerprints,
recipient hashes, policy epochs) so RECONSTRUCT operation is O(1) lookup, not O(n)
scan.
5. Lock-free state management: Use atomic operations or compare-and-swap for
nonce/state consumption to avoid blocking on contended locks.
6. Early validation: Perform cheap validation checks (nonce freshness, expiry) early; defer
expensive checks (revocation, policy verification) to finality if possible.
User-Perceptible Latency Scenarios
Scenario 1: Message send (most common)
User taps send
Secure screen shown (500-2000ms, user reads and taps confirm)
Crypto validation happens in background (~10-15ms, masked by UI)
Message sent to network (~100-500ms)
User sees "message sent"
Total user-perceptible latency: 500-2500ms (dominated by UI and network, not
crypto)
Scenario 2: File export with immediate finality
User confirms file export
Protected validation runs (10-15ms, happens before UI)
Finality Sink verification runs in background (~5-8ms)
File is encrypted and transmitted to network (~500-5000ms for large file)
User sees "export complete"
Total user-perceptible latency: 500-5000ms (dominated by encryption and
network, not validation)
Scenario 3: Payment authorization
User taps pay
Secure screen shown (500-2000ms, user confirms)
Protected validation happens in background (10-15ms, masked by UI)
Capability issued
Payment processor verifies capability (5-8ms)
Payment network processes transaction (~500-2000ms)
User sees confirmation
Total user-perceptible latency: 500-4000ms (dominated by network and payment
processing, not crypto)
Scenario 4: Rapid-fire user actions (edge case)
User sends 5 messages in quick succession (1 message per 2 seconds)
Each message triggers validation (~10-15ms)
If validation is asynchronous, user perceives no additional latency
If validation is synchronous and blocks, user perceives ~15ms delay per message,
noticeable only if they're watching closely
Measurement and Monitoring
Before deployment, latency impact should be measured empirically:
Baseline: Measure end-to-end latency for representative operations (message send,
file export, payment) without proposed architecture.
With architecture: Measure same operations with protected-validation and finality-sink
code paths.
Breakdown: Separately measure validation time, finality check time, UI time, and
network time.
User perception: Conduct usability testing to determine if users notice any difference
(perceptible latency threshold is ~100ms for interactive operations).
Stress test: Measure at high scale (100 rapid actions per minute) to identify
serialization bottlenecks.
Expected result: User-perceptible latency unchanged or <50ms additional delay
(imperceptible to most users).
Processor Architecture Dependency
Different mobile platforms have different processor architectures:
Apple (A-series):
Dedicated Secure Enclave coprocessor
Hardware cryptographic accelerators (AES, SHA, ECC)
Async callbacks from Secure Enclave to main processor
Expected additional latency: minimal (<1ms user-perceptible)
Android (Qualcomm, MediaTek):
Secure processor (Qualcomm Secure Processor, MediaTek Secure Enclave)
Hardware cryptographic accelerators
May require inter-processor communication (IPC)
Expected additional latency: minimal to moderate (1-10ms user-perceptible, depending
on IPC efficiency)
Generic/RISC-V:
May not have dedicated secure coprocessor
Cryptographic operations may run on main processor
Lock contention possible if validation competes for processor resources
Expected additional latency: moderate (10-50ms user-perceptible)
Recommendation: Implement on platforms with hardware-isolated Secure Enclave and
cryptographic accelerators (Apple, high-end Qualcomm, high-end MediaTek) first; optimize
for broader platforms later.
Conclusion on Latency
Under typical usage patterns and with asynchronous processing, the additional
latency introduced by this architecture is imperceptible to users.
The 10-15ms validation and 5-8ms finality checks are dwarfed by:
UI confirmation time (500-5000ms)
Network latency (100-500ms for messages/payments, 500-5000ms for file transfers)
User interaction time (1-30 seconds for composition)
The architectural property is sound; latency is an implementation and platform-
specific optimization task.
Critical implementation requirement: Validation and finality checks must be
asynchronous or offloaded to coprocessors. Synchronous blocking on the main
processor would produce user-perceptible slowdown and must be avoided.
Memory and Device Stability
The architecture creates and verifies several data structures (Candidate Device Act, LAVR,
capability, nonce/state). The question is: does this consume excessive RAM, cause memory
pressure, or create conditions for device hangs?
Where Memory Is Used
Per-request memory overhead:
Candidate Device Act:
Requester ID: 32 bytes
Operation type: 8 bytes
Resource identifier/fingerprint: 32 bytes
Destination/recipient: 64 bytes (email, contact ID, payment account)
User-intent evidence: 64 bytes (biometric data reference, secure screen hash)
Nonce: 16 bytes
Policy version: 8 bytes
Security epoch: 8 bytes
Timestamp: 8 bytes
Additional metadata: 64 bytes
Subtotal: ~300 bytes per Candidate Device Act
LAVR (Protected Validation Receipt):
Validation commitment hash: 32 bytes
Nonce reference: 16 bytes
Policy version: 8 bytes
Security epoch: 8 bytes
Finality Sink identifier: 32 bytes
Signature: 64 bytes (ECDSA P-256)
Timestamp: 8 bytes
Additional metadata: 64 bytes
Subtotal: ~232 bytes per LAVR
Non-bearer Capability:
Validation commitment hash: 32 bytes
LAVR reference: 32 bytes
Nonce: 16 bytes
Finality Sink identifier: 32 bytes
Expiry timestamp: 8 bytes
Effect count: 8 bytes
Signature: 64 bytes
Additional metadata: 32 bytes
Subtotal: ~224 bytes per capability
Nonce/State Entry:
Nonce: 16 bytes
Consumption state (consumed/reserved): 8 bytes
Timestamp: 8 bytes
Associated capability ID: 32 bytes
Revocation flag: 1 byte
Security epoch: 8 bytes
Subtotal: ~73 bytes per nonce entry
Total RAM per operation (end-to-end): ~300 + 232 + 224 + 73 = ~829 bytes
Lifetime of Data Structures
Critical insight: These structures are temporary, not persistent.
Candidate Device Act:
Created when request arrives
Discarded after LAVR creation (if validation fails) OR after capability is issued (if
validation succeeds)
Lifetime: ~10-15ms (duration of validation)
Storage: Transient, stack or temporary heap allocation
LAVR:
Created after validation succeeds
Bundled with capability
Discarded after Finality Sink verification OR after expiry (typically 30-300 seconds)
Storage: Transient, temporary heap or protected state storage
Capability:
Created after validation succeeds
Held in memory or passed to Finality Sink
Consumed (nonce marked used) after effectuation
Discarded after consumption
Lifetime: 30-300 seconds (user confirmation time + network transmission)
Storage: Transient, temporary heap
Nonce/State Entry:
Created with capability
Marked consumed after effectuation
Retained for revocation checks and audit (~1 hour to 24 hours)
Purged during periodic cleanup
Storage: Protected state storage (Secure Enclave or secure database)
Memory Constraints Under Typical Usage
Typical user workflow:
Send 10 messages per hour = 10 concurrent operations at peak
Each operation: ~829 bytes RAM
Peak RAM for in-flight operations: ~10 829 bytes = ~8.3 KB
Add nonce/state entries (retained for 24 hours):
10 messages/hour 24 hours = 240 entries per day
Each entry: ~73 bytes
Daily nonce/state storage: ~17.5 KB
Add LAVR receipts (retained for 7 days for audit):
240 entries 7 days = 1,680 entries
Each LAVR: ~232 bytes
Weekly LAVR storage: ~390 KB
Total memory footprint for typical user:
In-flight operations: ~8 KB (transient, released immediately)
Daily nonce/state: ~17.5 KB (grows, cleaned up after 24 hours)
Weekly LAVR: ~390 KB (grows, cleaned up after 7 days)
Total: ~415 KB
Comparison to iPhone baselines:
iPhone 15 RAM: 8 GB = 8,000,000 KB
Proposed architecture overhead: 415 KB
Percentage: 0.005% of available RAM
Where Memory Pressure COULD Arise (Poor Implementation)
These risks are implementation-level, not architectural:
1. Unbounded nonce/state accumulation: If nonces and state entries are never garbage-
collected (no expiry, no cleanup), memory grows without bound. After 1 month of typical
usage, could consume tens of megabytes.
2. Persistent Candidate Device Acts: If rejected requests keep Candidate Device Acts in
memory (e.g., for audit), and no cleanup policy exists, memory pressure grows.
3. Large LAVR storage: If LAVR receipts are persisted to disk but never pruned, storage
grows unbounded. For a power user (1,000 actions per day), receipts could consume
232 KB/day = 84.8 MB/year.
4. Revocation list explosion: If the revocation list (set of all revoked capabilities) is stored
in RAM without compression or pruning, it could grow unbounded.
5. Concurrent operation storms: If the system receives 10,000 requests per second
(DDOS or malicious app), and each creates a temporary Candidate Device Act in RAM,
peak memory could spike to ~8.3 MB. If cleanup is delayed, memory pressure
accumulates.
6. No memory pooling: If each operation allocates fresh memory and doesn't use memory
pools or pre-allocation, fragmentation reduces effective available RAM.
7. Infinite loops in validation: If a validation check hangs or loops (e.g., revocation check
against a slow or unavailable service), memory is held until timeout expires.
Crash Recovery and State Consistency
Concern: If the device crashes or hangs while a capability is in flight, could
nonce/state be corrupted, lost, or duplicated?
Answer: This is addressed by atomic finality and protected state.
Scenario: Device crashes after LAVR is committed but before capability is consumed.
1. User sends message; validation succeeds; LAVR committed to protected storage
2. Capability issued and passed to message-send Finality Sink
3. Device crashes before message-send Finality Sink atomically consumes the nonce
On device recovery:
Protected state (LAVR, nonce/state entries) is recovered from persistent protected
storage
Capability is lost (not persisted, only transient)
Message-send Finality Sink checks nonce status: not consumed
Capability must be re-issued OR user must re-approve
Message is NOT sent twice (nonce prevents replay)
Result: No corruption, no duplicate effectuation. The atomicity of the finality operation
prevents the nonce from being consumed without the effect occurring.
Implementation Optimizations (If Needed)
1. Nonce/state garbage collection: Implement background cleanup task that purges
expired nonces (>24 hours old) daily.
2. LAVR pruning: Implement retention policy: keep LAVR for 7 days for audit, then delete.
Compress old LAVR entries (archive to disk if needed for regulatory compliance).
3. Revocation list compression: Use bloom filters or cryptographic accumulators instead
of explicit lists to reduce revocation check memory footprint.
4. Memory pooling: Pre-allocate fixed-size memory pools for Candidate Device Acts,
capabilities, and LAVR to reduce fragmentation.
5. Transient cleanup: Ensure Candidate Device Acts are freed immediately after
validation, not held until garbage collection.
6. Async cleanup: Move garbage collection and pruning to background thread so main
processor is not blocked.
7. Rate limiting on concurrent operations: If system detects more than N in-flight
operations, reject additional requests until some complete. Prevents memory exhaustion
under DDOS.
Device Hang Scenarios
Concern: Could the architecture cause the device to freeze or hang?
Scenario 1: Validation takes too long
User sends message; validation hangs on revocation check (service unavailable)
Main processor blocked waiting for result
UI becomes unresponsive
Prevention:
Validation must have timeout (e.g., 5 seconds)
On timeout, fail closed: DENY the operation
Never leave user with hanging operation
Scenario 2: Memory exhaustion causes out-of-memory (OOM) crash
Device accumulates LAVR, nonces, and state without cleanup
After weeks of heavy usage, allocated memory exhausted
iOS kills app or kernel panics
Prevention:
Implement mandatory garbage collection (>1 month, purge all LAVR)
Implement emergency cleanup (if free RAM <100MB, purge LAVR and old nonces
immediately)
Monitor memory usage and alert if approaching threshold
Scenario 3: Lock contention on nonce/state causes deadlock
Multiple threads attempt to consume the same nonce simultaneously
Lock on nonce/state entry is held too long
Other threads starve; device appears hung
Prevention:
Use lock-free algorithms (compare-and-swap, atomic operations) for nonce
consumption
Keep critical section duration <1ms
Never hold locks across I/O operations
Scenario 4: Revocation check against remote service blocks finality
Finality Sink must check revocation before effectuating
Revocation check requires network round-trip (~100-500ms)
If network is slow, finality blocks and user perceives hang
Prevention:
Cache revocation status locally; update asynchronously
Use cached status for finality check (fail-safe: conservative default if cache is stale)
Perform network-based revocation check asynchronously after effectuation (for audit,
not for authorization)
Measurement and Monitoring
Before deployment, memory and stability impact should be measured empirically:
Memory baseline: Measure RAM usage during typical usage (100 messages, 10 file
exports, 5 payments over 24 hours) without proposed architecture.
With architecture: Same test with protected-validation and finality-sink enabled.
Measure peak RAM, steady-state RAM, and garbage collection overhead.
Long-duration test: Run device for 7 days of heavy usage (1,000 actions per day).
Monitor for memory leaks, OOM crashes, or hangs.
Stress test: Trigger 100 rapid operations per minute for 1 hour. Measure peak memory
and identify serialization bottlenecks.
Crash recovery test: Simulate device crashes at various points (during validation,
during finality, after consumption). Recover and verify nonce consistency.
Expected result:
Peak RAM increase: <10 MB (undetectable on 8 GB device)
Steady-state RAM: <500 KB (0.006% of device RAM)
OOM crashes: none (with proper garbage collection)
Hangs: none (with timeouts and lock-free design)
Processor Core Assignment
Modern iOS/Android assign operations to different cores for stability:
Main UI thread: Responsive to user input; must not be blocked
Background thread: Validation, LAVR creation, state updates
Secure Enclave: Cryptographic operations, protected state management
Network thread: Network requests, asynchronous I/O
Optimal assignment:
Candidate Device Act creation: Main thread or background (transient, <1ms)
Protected validation: Secure Enclave (coprocessor, no contention)
LAVR/capability creation: Secure Enclave (coprocessor)
Finality Sink verification: Background thread or Secure Enclave
Nonce consumption: Protected state (atomic, no blocking)
Revocation check: Background thread with timeout
Result: No single core is overloaded; no core contention; no hangs.
Conclusion on Memory and Stability
Under typical usage patterns and with proper implementation (garbage collection,
timeouts, lock-free design, async processing), the architecture does not introduce
measurable memory pressure or stability issues.
Memory overhead is bounded:
Per-operation: ~829 bytes (transient)
Persistent state: ~415 KB for typical daily usage
Percentage of device RAM: <0.01%
Device hang risk is mitigated by:
Timeout mechanisms on validation
Mandatory garbage collection
Lock-free or short-critical-section state updates
Async processing to avoid main thread blocking
Rate limiting on concurrent operations
The architectural property is sound; memory management and crash recovery are
engineering requirements.
Critical implementation requirements:
1. Validation must timeout (fail-closed on slow services)
2. Garbage collection must be mandatory and periodic
3. Nonce/state updates must be atomic and lock-free
4. Main thread must not block on validation or revocation checks
5. Device recovery must restore nonce/state consistently
What This Architecture Does NOT Solve: Acknowledged
Limitations
*The architecture is deployable incrementally on existing platforms. Hardware
redesign is not a prerequisite for obtaining meaningful execution-finality
protection; it may be required only where the desired assurance level demands
demonstrable mediation of every relevant hardware and firmware effectuation
path.
This section explicitly addresses the three most serious engineering objections. The
architecture has genuine limitations that affect the strength of security guarantees in
particular threat models. These limitations do not prevent deployment on existing hardware;
they distinguish between practical protection at mediated boundaries and mathematical
completeness against hardware-level bypass.
Limitation 1: Attested Egress Completeness-Assurance Strength vs.
Practical Protection
The distinction: The architecture can provide practical protection at identified CPU-
mediated consequence-producing boundaries (message send, file export, payment, etc.).
However, proving that NO unmediated path exists around the Finality Sink requires complete
mediation of every hardware pathway, which is unachievable on existing systems.
Why: Modern System-on-Chips (SoCs) have deeply complex and often undocumented
hardware pathways:
Direct Memory Access (DMA) engines can access main memory without going
through the CPU or Finality Sink
Proprietary baseband controllers (cellular modem) run closed-source firmware and
have independent access to network I/O
Coprocessors (GPU, media engines, neural processing units) have direct memory
access and may bypass CPU-level controls
Vendor firmware blobs (WiFi, Bluetooth, storage controllers) execute with elevated
privileges and often without source code visibility
Side-channel paths (shared caches, memory timing, thermal channels) could
potentially leak data without crossing monitored egress boundaries
What this means for deployment:
Practical protection is achievable: Protecting message send, file export, and payment
through CPU-mediated Finality Sinks prevents ordinary application-level and privilege-
escalation attacks.
Complete assurance is not achievable: If the threat model includes compromised
DMA engines, baseband firmware, or peripheral controllers, existing hardware cannot
establish absolute closure.
Example of practical protection: An attacker who compromises the message-composition
assistant cannot use that compromise to send messages through the message-send Finality
Sink without satisfying validation. This is practically useful even if a hypothetical baseband
compromise could potentially bypass the message-send pathway entirely.
Example of assurance limitation: An attacker who controls the WiFi firmware could
theoretically read memory addresses containing user messages and transmit them over the
network without going through the message-send Finality Sink. Defending against this
requires deeper hardware integration.
The honest truth: Proving absolute mathematical closure across every physical egress path
on existing iPhone, Snapdragon, MediaTek, or RISC-V hardware is not practically achievable.
Vendors do not disclose complete memory maps, DMA routing, or firmware capabilities.
This is not a flaw in the architecture's deployability; it is a property of existing
hardware.
Limitation 2: Maximum-Assurance Completeness-Optional
Hardware Support
The distinction: The architecture provides practical protection on existing hardware.
Proving complete mediation of every hardware pathway-defending against DMA bypass,
baseband compromise, and firmware attacks-requires deeper hardware integration and is
optional based on threat model.
Where new hardware could help: If the threat model requires defense against
compromised DMA engines, baseband processors, or peripheral firmware, deeper
integration is valuable:
Optional SoC enhancements could include:
Mandatory routing of critical egress paths through the Protected Execution Domain or
Finality Sink
Hardware-enforced memory protection preventing DMA engines from accessing
unmediated memory regions
Encrypted and authenticated inter-core communication
Cryptographic attestation of all firmware components before execution
Removal or strict mediation of undocumented firmware blobs
Optional controller redesign could support:
Baseband modems that route all network I/O through the Finality Sink
Storage controllers that cannot directly access user data without validation
Peripheral controllers (WiFi, Bluetooth, USB) that cannot bypass the finality boundary
What this means for deployment:
Deployment on existing hardware is viable today without waiting for hardware
changes
Stronger assurance is optional: If the threat model includes hardware-level
compromise, deeper integration may be appropriate
No prerequisite for baseline interoperability: The architecture provides security
benefit on iPhone 15 or Snapdragon 8 Gen 3 without redesign
Timeline perspective: Hardware redesign is not a path for baseline deployment; it is an
optional enhancement for higher-assurance requirements. Chip design cycles (3-5 years)
and adoption cycles (7-10 years) are not relevant to near-term interoperability deployment.
The honest truth: Complete mediation of every hardware pathway is difficult on existing
systems but not required for practical protection of designated consequence-producing
boundaries.
This is not a prerequisite for deployment; it is an optional assurance enhancement.
Limitation 3: Semantic Normalization-Software Engineering
Complexity, Not Architectural Flaw
The distinction: The architecture establishes the technical mechanism (protected
validation + finality verification) for enforcing execution authority. Defining which application
intents decompose into primitives, and how to present multi-step workflows without
usability friction, is a software engineering problem, not an architectural limitation.
Example 1: The BookTrip intent
User says to assistant: "Book a flight to Tokyo on August 25 for $500"
The assistant must:
Query flight database (network access)
Present options to user (UI interaction)
Charge user's payment account (payment initiation)
Send confirmation email (message send)
Update airline account (cross-origin, multi-step transaction)
Synchronize with calendar (storage write)
Problem: This is not a single, atomic consequence. It is a multi-step workflow with side
effects, conditional branches, and inter-service dependencies. Mapping it to a single
"BookTrip" primitive requires either:
A rigid, pre-defined workflow (blocks custom travel agents, breaks interoperability)
Decomposing it into many micro-primitives (send network request -> export file -> write
storage -> initiate payment), each requiring separate user approval (massive usability
friction)
Trusting the assistant to handle the workflow steps on its own (defeats the
architecture's security model)
Example 2: The TransferMoney intent
User says: "Send $100 to Alice for rent"
The assistant must:
Identify "Alice" (contact resolution, could match multiple contacts)
Determine the payment method (bank account, Venmo, PayPal, etc.)
Check regulatory constraints (daily transfer limits, sanctions screening)
Execute the transfer (irreversible financial transaction)
Log for tax purposes
Problem: The consequence is not "transfer money." It is "identify recipient -> select
payment method -> comply with regulations -> transfer -> audit log." Each step has failure
modes and edge cases.
Example 3: The PublishInvoice intent
User says: "Send invoice #12345 to acme@corp.com"
The assistant must:
Verify the invoice exists and is ready (query)
Verify the recipient email is correct (confirmation)
Generate the PDF or attach the document (computation)
Send via email (network send)
Update invoice status to "sent" (storage write)
Problem: This looks like a simple action but involves querying, computing, validating,
networking, and storage. Each substep could fail. If user says "send the wrong invoice", is
this a security flaw (assistant violated user intent) or a usability flaw (assistant did what it
was told)?
The honest truth: Defining which intents map cleanly to primitives, and how to decompose
complex workflows without introducing usability friction or false denials, requires careful
software engineering. Different deployments may make different choices:
1. Strict primitive decomposition: Each substep (query, compute, validate, transmit)
requires separate user approval. Stronger security, higher friction.
2. Workflow templates: Pre-defined, tested workflows (BookTrip, TransferMoney) are
treated as single intents. Lower friction, requires upfront definition.
3. Escalation to trusted service: Complex workflows are delegated to a trusted
intermediary service that decomposes them internally. Balances security and usability.
4. Progressive disclosure: Show user the workflow structure; ask for approval at critical
gates (spend money, access data), not at every step. Medium friction.
This is a software engineering choice, not an architectural limitation. Different
platforms and use cases will optimize differently. The architecture provides the enforcement
mechanism; the application design determines the user experience.
This is not a flaw in the architecture; it is a design decision in the implementation.
Deployment on Existing Systems and the Role of Hardware Redesign
*The architecture is deployable incrementally on existing platforms. Hardware
redesign is not a prerequisite for obtaining meaningful execution-finality
protection; it may be required only where the desired assurance level demands
demonstrable mediation of every relevant hardware and firmware effectuation
path.
The proposed architecture does not require a fundamental redesign of the operating
system, application ecosystem, or device hardware as a prerequisite for practical
deployment.
The principal deployment objective is to introduce protected validation and execution-
finality enforcement at existing consequence-producing boundaries. Depending on the
platform, these boundaries may include:
Message dispatch
Network egress
File export
Payment authorization
Persistent-storage commit
Sensor release
Privileged device control
Equivalent system interfaces
Accordingly, applications and AI assistants do not need to be completely redesigned around
a new execution environment. They may continue to perform ordinary computation,
reasoning, content generation, workflow orchestration, and request preparation through
existing mechanisms. The principal architectural change occurs when a requested operation
is capable of producing a protected external consequence.
At that point, the operation is treated as a non-effective Candidate Act. Protected
infrastructure validates the relevant security attributes, establishes protected validation
evidence, and creates bounded execution authority. The relevant Finality Sink then verifies
that authority against the actual consequence presented for release before permitting
effectuation.
Incremental Deployment on Existing Hardware
A practical implementation may therefore be introduced incrementally.
Initial deployment may protect selected high-consequence operations:
Message transmission
File or data export
Payment initiation
Sensitive sensor disclosure
Persistent security-relevant state changes
Privileged device-control operations
Existing applications may continue to use their ordinary APIs. Platform-level adapters,
security services, protected execution facilities, or controller-level enforcement
mechanisms may translate sensitive operations into the execution-finality path.
This approach does not imply that implementation requires no platform changes.
Operating-system frameworks, security services, drivers, controllers, APIs, or protected
execution components may require modification or extension so that designated
consequential operations cannot bypass the applicable Finality Sink.
The important distinction is between targeted integration and fundamental platform
redesign.
The architecture can provide meaningful execution-finality protection through targeted
integration with existing systems. Replacement of the complete operating system,
application ecosystem, or system-on-chip is not a prerequisite for obtaining that security
benefit.
Stronger Assurance Through Deeper Hardware Integration
A different question arises if the required security objective is not practical protection of
designated consequential operations, but complete mediation of every physical path
capable of producing the protected consequence-including paths involving compromised
DMA engines, baseband processors, peripheral firmware, coprocessors, or other hardware
components capable of bypassing ordinary CPU-mediated controls.
Existing commercial hardware may not expose sufficient control over every such
pathway to establish complete mediation.
For deployments requiring this substantially stronger threat model, deeper hardware
integration-and in some implementations future SoC or controller redesign-may be
appropriate. Such redesign could provide:
Hardware-enforced routing of all egress
Stronger DMA isolation
Authenticated controller communication
Firmware attestation
Equivalent mechanisms preventing alternative effectuation paths
This represents a higher-assurance implementation option, not a prerequisite for
deployment of the architecture itself.
Deployment Model: Incremental, Not Sequential
The distinction is therefore:
Existing systems: Practical execution-finality enforcement can be introduced at identified
consequence-producing boundaries through incremental platform integration. This is
deployable today.
Higher-assurance systems: Additional hardware support may progressively increase the
completeness of effectuation-path mediation as platforms evolve.
Maximum-assurance systems: Where the security requirement includes demonstrable
closure of every relevant hardware and firmware bypass path, purpose-designed hardware
may ultimately be useful.
The architecture therefore does not depend on waiting for a future generation of
devices before providing useful security properties. Its deployment model is
incremental: protect consequential boundaries that can be mediated today, expand
mediation as platform integration increases, and use deeper hardware support where the
required assurance level justifies it.
Proportional Security Claims
The security claim should remain proportional to the implementation.
An implementation should not claim complete effectuation-path mediation unless every
relevant path has actually been shown to be mediated. Where existing hardware contains
unverified or unmediated pathways, those pathways remain part of the residual threat
model.
This limitation does not prevent deployment of execution-finality controls at the pathways
that can be reliably mediated. It instead separates the usefulness of the architecture from
the strength of the assurance claim made for a particular implementation.
Result: The message shifts from "Europe must wait for new silicon" to "deployment can
begin at existing enforcement boundaries; hardware redesign is relevant only if a
deployment demands a stronger completeness guarantee against hardware-level bypass."
Honest Assessment
This architecture provides meaningful security improvement on existing hardware
through targeted deployment at identified consequence-producing boundaries. It is
not a panacea; it does not solve every attack vector or every usability problem.
What it does solve:
Prevents an untrusted third-party app from using a single, broad permission to exfiltrate
all user data (on mediated pathways)
Ensures that every sensitive action goes through a validation and finality gate at CPU-
accessible boundaries
Makes revocation possible and enforceable
Provides cryptographic audit trail of consequential actions
Distributes enforcement across multiple components (not single trust point)
Enables deployment incrementally without requiring wholesale platform redesign
What it does NOT solve (on existing hardware):
Attacks on undocumented hardware pathways (DMA, baseband, firmware blobs) that
bypass CPU-mediated controls
Mathematical completeness of path closure without deeper hardware integration or SoC
redesign
The software engineering challenge of mapping complex, non-deterministic workflows
into rigid primitives
Attacks that require compromising the Secure Enclave or Protected Execution Domain
itself
For regulators (EDPB, DG CONNECT, EU AI Alliance): The architecture provides a
practical path to compliant AI system interoperability on existing hardware, deployable
today. It is demonstrably better than current approaches. It is not perfect. The security
benefit can be obtained now through targeted integration at consequence-producing
boundaries. Stronger completeness guarantees (defending against DMA/baseband
compromise) are achievable through deeper hardware integration over time, not a
prerequisite for deployment.
For platforms (Apple, Qualcomm, Google): Deployment on existing hardware provides
measurable security benefit and demonstrates commitment to user control. Incremental
integration with existing APIs, security services, and enforcement mechanisms is achievable
without platform redesign. Options for deeper hardware support can be evaluated based on
the required threat model, not as a prerequisite.
For the inventor: The architecture's value is as a security model and regulatory framework,
deployable today, with a path to stronger assurance over time. Its power comes from:
1. Distributing enforcement across multiple components
2. Making revocation practical and enforceable
3. Proving that interoperability does not require uncontrolled delegation of authority
4. Creating a deployable path for platforms to comply with regulations without sacrificing
security
5. Enabling incremental integration without requiring wholesale platform redesign
These three limitations do not invalidate the architecture or prevent deployment. They
clarify its scope and distinguish practical deployability from maximum-assurance
guarantees. An honest, complete technical proposal acknowledges them upfront and
separates near-term deployment from long-term assurance strengthening.
Conclusion
Apple's security concern is valid: uncontrolled third-party execution authority on the
iPhone would create real risks of compromise, prompt injection, supply-chain attack,
and regulatory liability.
The EU's operational constraint is valid: interoperability must not be provided at the
cost of security or user control.
This architecture addresses both by separating participation from uncontrolled power.
A third-party assistant can participate in the user's workflows and request actions. But
participation is not authority. Every action is validated, every scope is narrow, every
capability is non-reusable and non-bearer, and every final gate is independently verified.
The security is not delegated to the third party. It is enforced by the platform.
The user is not passive. Intent is captured prospectively and remains revocable.
The regulator can audit the enforcement because it is cryptographic and hardware-
protected, not merely logged.
Thus, interoperability can be provided at the level of: "You may request this action
under the same technical conditions."
It does not require interoperability at the level of: "You receive unrestricted control
over the device."
========================================================================
PART II - ANTICIPATORY TECHNICAL OBJECTIONS AND RESPONSES
========================================================================
Technical Objections and Responses
Q1. How does the Protected Execution Domain know that the Candidate Act
accurately represents the real consequence?
The Candidate Act descriptor must not merely describe what software claims it intends to do.
It must function as a machine-verifiable commitment to the exact consequence that may
later be released.
This is necessary because the operating-system or mediation layer may participate in forming
the Candidate Act, while that layer is not itself trusted as the final authority for effectuation.
If the protected architecture merely validates a description authored by an untrusted layer, the
architecture risks validating a representation rather than the actual consequence.
The solution is to divide verification between two independent enforcement points:
The Protected Execution Domain validates authority over a commitment. The Finality
Sink validates that commitment against the actual consequence-producing state.
Neither verifier alone is sufficient.
The existing disclosure already constructs a Candidate Device Act containing the requesting
application or agent identity, action class, resource scope, destination scope, governance or
authority epoch, revocation epoch, nonce, and designated Finality Sink identity, and
maintains the Candidate Device Act in a non-effective state before effectuation.
A. The Candidate Act becomes a commitment
The Candidate Act should bind at least:
requesting application or agent identity;
sandbox, application measurement, or code-signature state;
action class;
resource identity;
resource commitment or digest;
destination identity;
destination commitment or digest;
user-intent object where required;
runtime-behavior state where applicable;
governance or authority epoch;
revocation state;
fresh nonce;
designated Finality Sink identity; and
designated Effectuation Boundary identity.
The Candidate Act is then canonicalized and committed through a digest or equivalent
protected commitment.
The important point is:
The descriptor is not trusted because it exists. It becomes useful only because its load-
bearing attributes are later checked against the actual release state.
B. Sink-side re-derivation, not sink-side trust
The Finality Sink must not simply accept fields such as resource_digest,
destination_digest, or payload_digest as assertions supplied by the requesting software.
Immediately before effectuation, the Finality Sink should independently derive the
effectuation-critical attributes from the actual object, payload, destination, or state transition
that it is about to release.
For example:
File export
The relevant digest should be derived from the actual file object, actual file version, or actual
bytes presented at the export boundary.
Message sending
The sink should verify the actual recipient, final message payload, attachment set, and
destination.
Payment
The protected payment boundary should verify the actual amount, currency, recipient,
account, transaction parameters, and finalization context.
Network transmission
The sink should verify the actual serialized outbound resource or payload and the actual
destination endpoint.
Sensor release
The sink should bind the actual sensor buffer or stream being released to the requesting
protection domain.
The conceptual comparison is:
AUTHORIZED_COMMITMENT =
HASH_CANONICAL(
action_class,
release_form_resource,
destination,
requester_identity,
sink_identity,
boundary_identity,
epoch,
nonce
)
ACTUAL_COMMITMENT =
HASH_CANONICAL(
actual_action_class,
actual_release_form_resource,
actual_destination,
actual_requester_identity,
actual_sink_identity,
actual_boundary_identity,
current_epoch,
nonce
)
IF ACTUAL_COMMITMENT != AUTHORIZED_COMMITMENT:
FAIL_CLOSED
The existing disclosure already requires Finality Sink verification against descriptor digest,
application identity, assistant identity, action class, resource digest, destination digest,
Finality Sink identity, epochs, nonce, and LAVR state. It also requires fail-closed denial
when these do not match.
The strengthening is to make explicit that the Finality Sink recomputes or re-derives these
values from the actual consequence-producing state, rather than merely re-reading the
same values originally supplied by software.
C. Release-form canonicalization, not request-form canonicalization
The commitment should correspond to the post-transformation, pre-release form of the
governed artifact.
This distinction is critical.
Between request formation and effectuation, data may be:
serialized;
compressed;
encoded;
transformed;
re-framed;
chunked;
wrapped;
encrypted;
combined with metadata; or
otherwise changed.
If the protected architecture commits only to the request-time representation, later
transformations may create either false mismatches or an opportunity for semantic
substitution.
The preferred rule is:
Commit to the last canonical or determinable representation before release, at a point
where withholding remains complete.
For example:
request object
v
transformation
v
serialization
v
FINAL DETERMINABLE RELEASE FORM
v
commitment / digest
v
Finality Sink verification
v
external consequence
Where a later transformation is unavoidable, such as protocol framing or transport
encryption, the Finality Sink should be positioned on the protected side of that transformation
and bind the last plaintext or canonical form whose identity can still be deterministically
established.
This release-form distinction is also important to any prior-art argument that differentiates
request-side or context-side digests from produced-output or release-side commitments.
If the disclosure is ambiguous about where the digest is computed, that distinction becomes
weaker. Making release-form commitment explicit strengthens both the architecture and that
prior-art position.
D. Split verification
The architecture should therefore be understood as having two distinct verification roles:
Protected Execution Domain
validates authority;
validates protected predicates;
verifies protected state;
verifies freshness and revocation;
commits validation evidence;
derives or authorizes the scoped capability.
Finality Sink
observes the actual consequence-producing state;
reconstructs or derives the release-form commitment;
verifies the scoped capability;
verifies sink and boundary identity;
compares actual release state with the protected commitment;
consumes or advances authority state;
permits effectuation only after successful comparison.
This avoids placing impossible semantic responsibility on the PED.
E. Residual semantic gap
Cryptographic and hardware enforcement can establish:
artifact identity;
resource identity;
requester identity;
destination identity;
sink identity;
boundary identity;
freshness;
policy epoch;
revocation state; and
protected authorization state.
They cannot by themselves establish higher-level meaning such as:
"This document is my medical record."
or:
"This person is the doctor I meant."
Meaning-level correctness must therefore come from a trusted user-intent mechanism where
the action class requires it.
For high-consequence classes such as:
identity disclosure;
credential release;
payment;
high-value transaction;
sensitive file export;
protected-data disclosure; or
equivalent irreversible acts,
a trusted-user-interface predicate should be treated as load-bearing.
Claim 5 already discloses a Trusted User-Interface Finality Sink using protected display,
secure input, protected transaction confirmation, biometric confirmation, PIN entry, or
equivalent trusted-user-interface mechanisms.
However, the current independent-claim structure does not necessarily make Claim 5
mandatory for every such class. That distinction should be preserved: technically
recommended strengthening is not automatically an existing independent-claim
requirement.
Q2. How do you guarantee that there is no bypass path around the Finality
Sink?
Bypass closure should not depend primarily on enumerating APIs, hooks, frameworks, or
software routes.
Enumeration is useful for patent coverage and design-around closure, but it does not itself
prove technical non-bypassability.
The stronger technical rule is:
The governed consequence must be physically or cryptographically impossible to
produce unless the required protected enablement material is present.
The Finality Sink should therefore control something necessary for effectuation, such as:
transmit-enable authorization;
queue-enable value;
hardware-unlock value;
memory-window unlock value;
storage-commit authorization;
decryption key;
rendering key;
secure dispatch authorization;
transaction-finalization authorization;
actuator enablement; or
equivalent protected technical material.
The filed disclosure already supports capability forms including hardware-unlock values,
queue-enable values, memory-window unlock values, network-transmit authorization,
storage-commit authorization, sealed handles, release keys, and equivalent technical
enablement conditions.
The preferred embodiment is therefore stronger than:
"Software checks whether the operation is permitted."
It becomes:
"The controller lacks the material required to complete the operation unless protected
finality has succeeded."
Conceptually:
ordinary software path
|
governed controller
|
+-- no valid protected enablement
| v
| cannot effectuate
|
+-- valid sink-bound enablement
v
Finality Sink
v
external effect
Governed Egress Set
For every governed consequence class, define a Governed Egress Set:
The complete set of technical boundaries through which that consequence can leave the non-
effective state.
Examples:
Data egress
network transmission boundary;
IPC boundary;
shared-memory release;
file-provider/export boundary;
removable-storage commit;
cloud-upload boundary.
Visible output
compositor;
trusted display release;
external display path;
protected rendering path.
Physical actuation
actuator controller;
radio controller;
device-control boundary;
equivalent physical-output controller.
Every member of the Governed Egress Set must either:
1. contain a Finality Sink; or
2. be structurally downstream of a Finality Sink and incapable of obtaining usable
governed material before successful verification.
This creates an auditable per-platform or per-SoC property.
The question becomes not:
"Did we remember every API?"
but:
"Is there any technical boundary through which this consequence can become
externally effective without possession of valid sink-verifiable enablement?"
Alternate routes remain governed
Browser upload, sharing-sheet transfer, SDK telemetry, cloud synchronization, app-intent
subcalls, accessibility actions, clipboard transfer, network sockets, diagnostic upload, IPC,
private-framework calls, or similar routes remain governed if they produce the same
consequence. The PCT already states this alternate-route principle.
The governing principle is:
Govern consequences, not APIs.
Adversary model
The security claim should also state what is and is not within the threat model.
The architecture may defend against compromise of:
an application;
AI assistant;
AI agent;
plug-in;
browser automation component;
user-space process;
ordinary operating-system service;
privileged framework;
automation service; or
alternate software route.
It should not claim to remain secure after compromise of:
the PED itself;
the trusted hardware root;
the cryptographic root of trust;
malicious silicon;
invasive physical attacks that defeat the assumed hardware security boundary.
A bounded adversary model makes the bypass guarantee credible and testable.
Q3. Where exactly is the first usable release boundary?
The architecture should not answer this merely by listing controllers.
It should provide a rule that generates the correct boundary even for platforms and action
classes not expressly listed.
The rule is:
The first usable release boundary is the last point at which the governed artifact
remains in a canonical or determinable form and complete withholding remains
possible, immediately before the act becomes usable, observable, transferable,
committed, rendered, transmitted, disclosed, paid, stored, actuated, or otherwise
consequential outside the non-effective state.
Two requirements must therefore be true simultaneously:
artifact identity remains determinable
AND
complete withholding remains possible
If the gate is placed earlier, an ungoverned downstream transformation may alter or complete
the act.
If the gate is placed later, the consequence may already have begun or the sink may no longer
be able to reconstruct the exact artifact being released.
The PCT already defines the Effectuation Boundary in first-use terms, and Claim 28
expressly refers to a first usable release boundary where the operation first becomes usable,
observable, transferable, committed, rendered, transmitted, disclosed, paid, stored, actuated,
or otherwise consequential.
Representative boundary mapping
Action class Correct first usable release boundary Preferred enablement
outbound egress after final payload and
Message / email attachment assembly, before external transmit-enable
transmission
first point where bytes become readable outside
File export export/read enablement
the originating protection domain
protected transaction-finalization or protected finalization
Payment
cryptogram-generation boundary authorization
Protected compositor submission or content-decryption decryption/render
rendering point immediately before usable rendering enablement
delivery from protected sensor/HAL path to
Sensor release sensor/DMA release
requesting protection domain
receiving application's paste/read boundary consumer-side read
Clipboard
where another principal first obtains content enablement
dispatcher handoff into the receiving protection
App intent / IPC dispatch authorization
domain
Accessibility input dispatcher immediately before target-
injection enablement
injection window delivery
Action class Correct first usable release boundary Preferred enablement
AI export / fully serialized outbound body immediately
transmit-enable
telemetry before egress
Persistent commit boundary where the state first becomes storage-commit
storage persistently usable authorization
Consumer-side finality
For some classes the consequence begins at consumption rather than emission.
Clipboard is a useful example.
Writing sensitive material into an isolated clipboard representation may not yet disclose it to
another principal. The disclosure occurs when another application obtains usable access to
that material.
Therefore:
Where the consequence begins at consumption, the Finality Sink should be located at
the consumer-side release boundary.
The same principle may apply to:
shared memory;
protected buffers;
deferred display;
encrypted content;
staged IPC objects; or
other contexts where production does not itself create the governed consequence.
Boundary identity must be bound
The same artifact released through different boundaries may create different consequences.
Therefore the capability should bind not only:
resource;
destination;
action class;
nonce;
epoch;
but also:
Finality Sink identity; and
Effectuation Boundary identity.
A capability valid for one boundary should fail when presented at another.
Feasibility
Q4. Can existing secure-enclave, TEE, secure-element, or equivalent protected
hardware implement the hot path without becoming a large new trusted
subsystem?
Yes, provided the architecture keeps the protected hot path fixed and small.
The PED should not become:
a general-purpose AI engine;
a full policy engine;
a natural-language interpreter;
a browser engine;
a model-inference system;
a regulator-rule interpreter;
or a bulk-data processor.
The PED need not process the bulk payload
A preferred implementation is:
Bulk hashing occurs at the Finality Sink, protected DMA path, crypto accelerator, or
other trusted boundary-adjacent component. The PED primarily handles fixed-size
commitments and protected state.
The PED may therefore maintain only relatively small objects such as:
digest / commitment
verification key
sink identity
boundary identity
nonce
nonce window
monotonic counter
governance epoch
revocation epoch
quota
capability state
LAVR state
protected policy state
The PCT already permits implementation using secure enclaves, TEEs, secure elements,
hardware security modules, protected processors, protected microcontrollers, protected
hypervisor partitions, or equivalent hardware-rooted or cryptographically isolated
environments.
Symmetric verification on the ordinary hot path
A useful implementation distinction is:
Hot-path capability verification
short-lived session key;
MAC or equivalent compact authentication;
nonce;
epoch;
sink identity;
boundary identity;
local protected-state check.
Durable evidence
LAVR;
protected signature where required;
receipt continuity;
external audit evidence;
non-repudiation material.
This allows ordinary low-risk finality to use a compact local primitive while reserving
heavier public-key operations for:
high-risk acts;
durable receipts;
external evidence;
attestation;
or events requiring stronger assurance.
The PCT supports multiple cryptographic forms rather than requiring one fixed cryptographic
suite.
Avoid protected-world transitions where possible
Repeated transitions into a protected execution environment may become more expensive
than the underlying cryptographic comparison itself.
A preferred implementation can therefore derive short-lived sink-verification material during
preparation:
PED
|
| derive / provision session-scoped verification material
protected sink-local state
|
| compact local capability verification
Finality Sink
The sink can then verify ordinary low-risk capabilities locally.
A new protected-world interaction may be required only when:
the session is established;
the governance epoch changes;
revocation state changes;
quota is exhausted;
a high-risk action occurs;
protected state must advance;
trusted user confirmation is required; or
fresh attestation is required.
The specification already distinguishes heavier authority preparation from a compact finality
hot path and permits pre-fetched state, cached state, capability-cache lookup, bounded
hardware-assisted verification, and freshness checks before use.
Existing protected hardware provides related primitives
The safer feasibility statement is not that existing secure hardware already implements this
entire architecture.
The stronger and more defensible statement is:
Existing protected hardware already supports closely related primitives such as
protected key custody, cryptographic verification, counters, attestation, sealed state,
secure transaction authorization, and hardware-backed isolation. The proposed
architecture composes such primitives into an execution-finality path.
That avoids overclaiming.
Performance figures should be treated carefully
Engineering estimates such as:
single-digit-microsecond MAC verification;
millisecond-scale secure-element signature operations;
tens-of-microseconds protected-world transitions;
sub-100-microsecond low-risk hot paths;
may be useful as illustrative engineering targets.
They should not be stated as universal architectural guarantees unless supported by
benchmarking on the relevant implementation.
The stronger patent and standards position is:
The hot path is bounded, fixed-function, local where possible, and independent of
unbounded AI reasoning or policy computation.
Incremental controller extension
Many Finality Sinks correspond to components that already control:
network transmission;
storage;
display;
IPC;
sensor delivery;
payment finalization;
device settings;
message sending; or
privileged dispatch.
The architectural delta is therefore:
Add sink-verifiable protected execution authority to an existing consequence-control
boundary.
The genuinely new load-bearing relationship is the combination of:
release-form commitment -> protected authority -> sink-local verification ->
effectuation.
Q5. How can low latency and high availability be preserved when every
consequential sub-action requires finality?
The unit of finality is the externally consequential or irreversible consequence, not every
syscall, function call, packet, fragment, token, or internal AI operation.
This distinction is essential.
One transfer can remain one Candidate Act
A large transfer may be divided into many packets or fragments while remaining one
bounded Candidate Act.
The capability may define a constrained envelope such as:
resource = X
destination = Y
action class = transfer
maximum bytes = N
maximum fragments = F
validity window = T
sink = Z
boundary = B
epoch = E
sequence / nonce range = R
The fragments remain authorized only while they remain within that exact bounded envelope.
Changing:
resource;
destination;
action class;
sink;
boundary;
epoch;
permitted byte count;
validity period; or
other load-bearing scope
requires new authority.
This preserves anti-fragmentation closure without requiring full reauthorization for every
individual transport fragment. Claim 32 already addresses fragmented Candidate Device Acts
and prevents fragmentation from defeating governance.
Risk-tiered finality
Different consequence classes can receive different verification depth.
Low-risk act
cached protected state
+
local sink verification
+
fresh nonce / sequence validation
+
compact authentication
High-risk act
fresh protected-state validation
+
trusted-user confirmation
+
fresh attestation where required
+
stronger protected evidence
+
fresh capability
Higher latency is easier to tolerate when a human confirmation step already exists.
The architecture should therefore avoid forcing the highest-assurance path onto every
operation.
Preparation may be speculative because preparation authorizes nothing
Authority preparation can safely occur before the final Candidate Act exists, provided that
preparation itself does not create externally usable authority.
For example:
current action executing
|
+-- refresh attestation
+-- prefetch policy state
+-- verify stable app state
+-- prepare session key
+-- load current epoch
+-- prepare likely sink context
If the anticipated act never occurs, nothing becomes externally effective because:
no final Candidate Act commitment exists;
no act-specific final capability has been verified;
no Finality Sink has permitted effectuation.
This means the architecture's safety property also becomes a performance advantage.
Multi-step AI workflows
A workflow may contain:
read calendar
v
summarize event
v
draft email
v
attach file
v
send message
Internal reasoning, planning, summarization, or drafting does not necessarily require finality
merely because computation occurred.
Fresh finality is required when a step becomes externally consequential.
For example:
protected calendar-data release
v
file export into another protection domain
v
external message transmission
Each consequence can reuse stable session, app, device, model, and policy state while
receiving its own:
Candidate Act commitment;
nonce;
scoped authority;
Finality Sink verification.
The PCT already states that a capability issued for one action class does not automatically
extend to later consequential actions and that subsequent externally consequential operations
invoke their own finality sequence.
Availability
Fail-closed behavior creates a genuine availability dependency and should be addressed
explicitly rather than ignored.
The central rule should be:
Degraded mode may shorten the validation path; it must never waive Finality Sink
verification.
That preserves the architecture even during partial failure.
Offline operation
Where permitted, the PED may issue a protected local authority lease containing:
bounded validity period;
allowed action classes;
quota;
monotonic counter;
sink identity;
boundary identity;
governance epoch;
revocation epoch;
permitted resource or destination class.
The device may continue operating while the bounded lease remains valid.
Connectivity loss therefore does not itself force immediate denial.
When the quota, time window, epoch, or protected lease state expires:
deny rather than silently broaden authority.
Cached local verification
Stable predicates may remain locally cached while freshness-sensitive state continues to be
checked locally.
For example:
application measurement may remain stable;
current nonce must remain fresh;
revocation state must remain acceptable;
capability must remain sink-bound;
boundary identity must remain correct.
Delayed receipt synchronization
Where policy permits, protected receipts may be committed locally and synchronized after
connectivity is restored.
The receipt may be delayed externally without delaying the local protected commitment that
makes the finality decision auditable.
Failure of remote infrastructure
If a remote policy service or remote protected component becomes unavailable, the
architecture may rely on already-issued bounded local authority where such authority exists.
It must not reinterpret service unavailability as authorization.
The invariant is:
NO VALID SINK-VERIFIABLE AUTHORITY
=
NO EFFECTUATION
The PCT already permits precomputed state, local fast-path verification, short-lived delegated
authority, distributed protected execution, and batching of receipt updates while preserving
the controlling invariant that the Candidate Device Act remains non-effective until the
applicable Finality Sink verifies the required capability.
Core Architectural Position
The complete answer can be reduced to five non-negotiable technical rules:
1. The Candidate Act is a commitment, not merely a description.
The commitment binds the actual governed artifact, destination, requester, sink, boundary,
freshness state, and other load-bearing attributes.
2. The PED validates authority over the commitment; the Finality Sink validates the
commitment against reality.
The sink re-derives the release-form state from the actual artifact it is about to externalize.
3. Bypass resistance comes from withheld enablement, not from software-hook
enumeration.
Every member of the Governed Egress Set must require protected sink-verifiable enablement
before the governed consequence can occur.
4. The first usable release boundary is the last point where identity remains
determinable and withholding remains complete.
If the consequence begins at consumption, the sink moves to the consumer side.
5. Feasibility and performance come from keeping the protected root small and
separating preparation from finality.
The PED governs commitments, keys, epochs, nonces, counters, receipts, and authority. Bulk
computation, AI reasoning, transformation, and ordinary application processing remain
outside the smallest trusted root.
The resulting sequence is:
PROPOSED ACT
v
CANONICAL / RELEASE-FORM COMMITMENT
v
NON-EFFECTIVE STATE
v
PED VALIDATES AUTHORITY
v
LAVR / PROTECTED EVIDENCE
v
SCOPED NON-BEARER CAPABILITY
v
FINALITY SINK RE-DERIVES ACTUAL RELEASE STATE
v
COMMITMENT MATCH?
NO YES
v v
FAIL CONSUME /
CLOSED ADVANCE AUTHORITY
v
EFFECTUATE
The essential security statement is:
Protected authority was granted for X, and the boundary capable of producing the
consequence independently proves that the operation it is actually about to release is X
before the consequence becomes effective.
B. Additional Technical Objections and Responses
Q8. Who governs the policy bundle? If the platform operator authors the
policy that the PED enforces, who watches the watcher?
This is a real governance problem.
A protected execution environment does not solve neutrality merely because the policy is
enforced in hardware. If the same platform operator can define the policy bundle, sign it,
change it, and determine whether first-party and third-party requesters receive equivalent
treatment, then hardware enforcement can make an unfair policy more strongly enforceable
rather than making it neutral.
The parity invariant therefore cannot depend only on:
VALIDATE_REQUESTER_TYPE_PARITY(
policy_bundle = platform_supplied_policy
)
The stronger architecture separates policy enforcement from policy provenance and
accountability.
The PED should validate not only:
"Is this Candidate Act compliant with the current policy?"
but also:
"Is this the authorized, externally identifiable policy version that this device is
permitted to enforce?"
A policy bundle should therefore have a protected identity such as:
policy_bundle_digest
policy_version
governance_epoch
issuer_identity
validity_period
applicable_action_classes
parity_profile
signature / authorization chain
The digest of that exact policy bundle should be bound into:
the protected governance state;
Candidate Act validation;
the capability;
and, where appropriate, the LAVR or validation evidence.
The existing disclosure already makes policy state epoch-bound, revocation-aware and
capable of being bound into the Candidate Act or validation evidence, and it expressly rejects
unauthorized policy downgrade.
That is useful, but epoch integrity alone does not answer who is entitled to define the
policy.
External verifiability
A stronger governance implementation can add one or both of the following:
Multi-party authorization
The policy profile becomes valid only when authorized by more than one relevant authority,
for example:
platform authorization
+
independent governance / conformity authorization
+
optional enterprise / user policy component
The architecture already contemplates combined, threshold, co-signed, or jointly authorized
capability construction in distributed protected execution.
The same architectural principle can be applied to policy provenance where supported by the
implementation.
External transparency
The policy-bundle digest, version and parity profile may be externally committed so that an
auditor, regulator, conformity assessor, enterprise administrator, or other authorized verifier
can establish:
which policy was active;
when it became active;
whether it changed;
whether first-party and third-party acts were evaluated under the same published
profile;
whether a downgrade occurred.
The PCT already states that protected finality evidence may be independently verified rather
than relying solely on the platform operator's own statements.
A public or permissioned policy-transparency log would strengthen that property further.
If policy-bundle co-signature or external transparency logging is not expressly supported by
the existing priority disclosure, it should be treated as a future implementation or
governance extension, not automatically represented as an existing claim requirement.
The central principle is:
The platform may implement enforcement, but it should not be the only party capable
of proving what rules were enforced.
Q9. What prevents many individually authorized Candidate Acts from
composing into an unauthorized aggregate consequence?
Per-act finality alone does not solve aggregation.
An attacker may remain within the scope of every individual authorization while producing a
prohibited cumulative effect.
For example:
Read 1 -> authorized
Read 2 -> authorized
Read 3 -> authorized
...
Read 10,000 -> individually authorized
v
aggregate exfiltration
Nothing in a purely stateless per-act predicate necessarily detects that the aggregate
behavior has crossed a security or privacy threshold.
The answer is to make protected finality stateful across acts where the action class requires it.
The PED should support a cumulative authority budget or session-level aggregate
predicate.
Protected state may be keyed to combinations such as:
principal
+
application / agent
+
resource class
+
destination
+
action class
+
session
+
time window
+
governance epoch
and maintain values such as:
cumulative bytes disclosed;
number of records accessed;
number of recipients;
number of external destinations;
number of transactions;
total transaction value;
sensor-duration budget;
query count;
tool-call budget;
cross-domain disclosure count;
or equivalent bounded-use state.
Then:
IF single_act_valid
AND cumulative_budget_remaining:
permit
atomically decrement protected budget
ELSE:
deny
This is different from ordinary rate limiting.
The important property is that the budget is itself part of protected authority state and
cannot be reset by restarting the app, changing the agent process, replaying an old capability,
or fragmenting the operation.
The existing disclosure already contemplates quota state, monotonic counters, protected state
advancement and atomic consumption, so there is architectural support for this direction. It
also expressly addresses fragmentation under a shared aggregate descriptor.
However, the broader threat of N independently valid acts composing into an
unauthorized semantic aggregate should be stated explicitly.
The rule becomes:
Finality may be evaluated both per act and over the protected cumulative state created
by prior acts.
Q10. How can the PED verify declared_purpose when the declared purpose
originates from an untrusted agent?
It cannot prove the agent's subjective intent merely by inspecting the string.
That limitation should be stated directly.
A field such as:
declared_purpose = "send medical report to doctor"
does not prove:
that the agent is truthful;
that the actual operation serves that purpose;
that the recipient is actually a doctor;
that the selected file is actually the intended medical report.
Therefore:
Declared purpose is a policy-selection and consistency input, not proof of semantic
intent.
The PED may verify:
that the declared purpose is an allowed purpose class;
that the requested resource is permitted for that purpose class;
that the destination class is permitted;
that the action class is permitted;
that the user-intent object authorizes that purpose;
that the runtime behavior remains within the permitted execution profile.
But the string itself is not authoritative.
The PCT already says that model-generated statements, prompt text, tool plans, self-
declarations and natural-language descriptions do not constitute trusted authority and may not
substitute for machine-verifiable evidence.
The technically defensible formulation is:
Purpose validation constrains execution to an authorized purpose class; it does not
cryptographically prove the internal motive of an AI agent.
For high-consequence operations, declared purpose should therefore be corroborated by
stronger predicates such as:
trusted user intent;
actual resource identity;
destination identity;
action class;
session context;
data classification;
jurisdiction condition;
enterprise authorization;
or other machine-verifiable evidence.
Q11. How can a behavioral descriptor or ALF be enforced against a non-
deterministic AI model?
The behavioral envelope should not require the model to reproduce a deterministic token
sequence.
That would be unrealistic for systems affected by:
sampling;
temperature;
context variation;
tool responses;
retrieval inputs;
model updates;
runtime configuration;
or ordinary probabilistic inference.
The architecture should separate model identity from behavioral authority.
Static or relatively stable identity
ALF or equivalent model identity may bind:
registered model identifier;
model version;
code-signature digest;
weights or protected measurement where available;
inference-runtime version;
tool-policy version;
retrieval configuration class;
safety-policy version;
approved plug-in or connector set.
Dynamic runtime descriptor
The runtime descriptor may bind observable execution properties such as:
action classes invoked;
tool classes used;
resources accessed;
destinations selected;
privilege level requested;
data classes accessed;
number or depth of delegated actions;
model configuration class;
approved context sources;
output class;
risk class;
protected execution trace digest;
or equivalent machine-verifiable runtime attributes.
The behavioral envelope should therefore be a predicate over observable execution
invariants, not an exact prediction of the model's generated text.
For example:
ALLOW:
model_id = approved
tool_class approved_set
destination_class approved_set
resource_class approved_set
delegation_depth <= N
high_risk_action => trusted_user_confirmation
DO NOT REQUIRE:
exact generated tokens == previously predicted tokens
Claim 46 already points in this direction by distinguishing model identity, approved
measurement or version, runtime behavioral descriptor, execution fingerprint or inference
trace, approved behavioral envelope, purpose scope, data-access scope and output class.
The stronger explanation is:
ALF answers "which model/runtime is executing?" Behavioral finality answers "what
classes of consequential behavior is this execution permitted to produce?"
The architecture should not claim that a non-deterministic model's entire future behavior can
be predicted.
Q12. How does the messaging embodiment work with end-to-end encryption if
the server-side PED cannot see plaintext message content?
This objection is valid against the server-side content-processing form of the named
messaging embodiment.
The current embodiment places a Platform Protected Execution Domain in server-side
protected infrastructure and describes AI processing over message content before delivery.
That implementation is feasible only where the relevant server-side protected component has
authorized access to the content being processed.
Where an interoperability deployment preserves end-to-end encryption such that the server-
side platform cannot obtain plaintext, the architecture should not require plaintext
disclosure to the server-side PED.
The enforcement point must move.
E2EE-compatible form
A stronger E2EE-compatible architecture is:
encrypted interoperable message
v
endpoint receives ciphertext
v
authorized endpoint decryption
v
CLIENT-SIDE / DEVICE-SIDE PED
v
Candidate Act for AI processing
v
local protected validation
v
local AI processing or protected processing
v
Candidate output
v
device-side Finality Sink
v
render / reply / export / agent action
The server-side protected component may still validate:
origin metadata;
interoperability context;
signed policy context;
sender-provided consent metadata;
routing authority;
capability provenance;
without accessing plaintext.
The PCT's broader architecture already permits on-device, remote, hybrid and distributed
PED placement, including split protected components.
Accordingly:
The general execution-finality architecture is compatible with E2EE, but the server-side
plaintext-processing form of Embodiment CC must be understood as one
implementation applicable only where server-side content processing is available. In an
E2EE deployment, content-dependent validation moves to the endpoint or another
protected domain that legitimately possesses plaintext.
This distinction should be explicit.
Q13. Does fail-closed behavior create a denial-of-service attack surface or leak
policy information through denial patterns?
Yes.
Fail-closed protects integrity, but it creates an availability dependency.
An attacker may attempt to exhaust or destabilize:
PED request queues;
nonce allocation;
attestation services;
revocation processing;
policy synchronization;
monotonic-counter state;
secure storage;
capability caches.
Therefore finality needs resource-governance protection, not merely authorization logic.
Possible measures include:
per-principal request quotas;
bounded PED queues;
admission control;
reserved capacity for critical action classes;
protected rate limits;
back-pressure before requests enter the secure world;
coalesced epoch updates;
bounded revocation windows;
local authority leases;
batch state advancement where safe;
wear-aware protected counters;
recovery checkpoints;
redundant protected services for deployments requiring higher availability.
The core rule remains:
A degraded validation path may be shorter, but degraded mode must not silently
convert missing finality authority into authorization.
Denial as a side channel
Different denial reasons may also reveal:
policy state;
revocation state;
user state;
security tier;
destination classification;
whether a protected resource exists.
Therefore the untrusted caller should receive a coarse or opaque denial result where
detailed reasons are not required.
For example:
CALLER:
FINALITY_DENIED
PROTECTED AUDIT:
exact internal denial reason
Detailed reasons may remain inside protected evidence accessible only to an authorized
auditor, user, administrator, or conformity authority.
The PCT already uses fail-closed denial extensively and contemplates protected denial
receipts.
The architecture should therefore state honestly:
Finality converts unauthorized effectuation into denial; it does not eliminate denial-of-
service as a security problem. Availability must be separately engineered.
Q14. Can the architecture realistically be deployed on the existing installed
device base?
Not with the strongest hardware-non-bypass guarantees on every existing device.
The market size and the immediately deployable hardware base should not be treated as the
same thing.
The existing disclosure identifies a very large installed device market. That establishes
potential scope, but not universal retrofit feasibility.
A credible deployment model has tiers.
Tier 1 - software / existing protected-hardware implementation
Where an existing device already exposes suitable:
TEE;
secure processor;
protected controller;
hardware-backed keys;
secure counters;
kernel mediation;
protected display or payment paths,
some execution-finality functions may be introduced through firmware, OS, driver, or
protected-service updates.
This may provide meaningful enforcement but not necessarily the strongest silicon-level non-
bypass guarantee for every action class.
Tier 2 - firmware/controller-integrated implementation
New firmware or platform releases can integrate capability verification directly into:
storage controllers;
network paths;
display pipelines;
IPC dispatchers;
sensor paths;
protected services.
Tier 3 - silicon-integrated implementation
The strongest Governed Egress Set model may require new SoC or controller design so that
protected enablement is structurally required at consequence-producing boundaries.
Therefore the commercially defensible position is:
The installed base defines the economic relevance of the problem; the deployable base
depends on the protected capabilities of each hardware generation. Full hardware-
rooted non-bypass enforcement may phase in with future device generations.
That is more credible than implying immediate retrofit of every existing device.
Q15. What happens when a multi-step workflow partially completes and a
later Finality Sink denies the next act?
Execution finality cannot magically undo an act that has already become irreversible.
This should be stated explicitly.
Suppose:
Act A -> authorized and effectuated
Act B -> authorized and effectuated
Act C -> denied
The architecture can guarantee that Act C does not occur without authority.
It cannot necessarily restore the external world to the state before Acts A and B.
Therefore distributed workflows require a separate workflow-commit discipline.
Where reversible preparation is possible
Use a prepare/commit structure:
Act A -> PREPARED
Act B -> PREPARED
Act C -> PREPARED
all required sinks ready?
v
YES
v
issue commit authority
v
effectuate
A workflow-level descriptor may bind:
workflow identifier;
required sub-acts;
dependency graph;
participating sinks;
resource commitments;
destinations;
validity window;
commit order.
No sub-act becomes externally effective during the preparation stage.
Where true atomicity is impossible
Some consequences cannot be atomically committed across independent systems.
For example, once an external message has been delivered or a physical actuator has moved,
rollback may be impossible.
In those cases:
perform the least reversible actions last;
reserve or stage reversible actions first;
stop immediately on denial;
record exact partial-completion state;
invoke compensating actions where meaningful;
do not describe compensation as rollback;
expose partial-completion status to the authorized user or orchestration layer.
The bounded claim should therefore be:
Execution finality prevents unauthorized sub-actions. It does not by itself guarantee
atomic rollback across independent irreversible external systems.
If a formal multi-sink commit protocol is not expressly supported by the existing priority
disclosure, it should be treated as an additional implementation refinement rather than silently
read into the current claims.
C. Regulatory and Political Objections and Responses
Q16. Does hardware-rooted finality entrench the platform gatekeeper by
moving the chokepoint from software into hardware?
It could, if the platform remains the sole authority over:
policy definition;
PED state;
capability issuance;
parity rules;
and verification evidence.
That would merely move discretionary control into a harder-to-observe layer.
The architecture therefore needs verifiable neutrality, not merely hardware enforcement.
Three independent properties are required:
1. Policy transparency
The exact policy bundle or policy profile being enforced should have a stable, externally
verifiable identity.
2. Parity verifiability
Equivalent first-party and third-party Candidate Acts should be independently testable against
equivalent predicate profiles.
The verifier should be able to establish:
same action class
same resource class
same destination class
same risk class
same user-intent condition
v
equivalent predicate treatment
without trusting the platform's assertion that parity occurred.
3. Independent evidence
The LAVR or equivalent validation evidence should allow an authorized external party to
verify:
active policy digest;
Candidate Act class;
relevant predicate profile;
capability scope;
sink identity;
finality decision.
The PCT already states that finality evidence can be independently verified rather than
relying solely on gatekeeper-controlled statements or post-event logs.
A stronger implementation may use:
externally published policy digests;
conformity profiles;
multi-party policy authorization;
threshold capability issuance;
independent test vectors;
standardized parity predicates.
The regulatory answer is therefore:
The platform may host the enforcement hardware, but it must not be the sole source of
truth regarding what policy was enforced or whether equivalent requesters received
equivalent treatment.
Q17. Does placing a Finality Gate on accessibility pathways create a barrier
for assistive technology?
A blanket hardware gate applied indiscriminately to accessibility functions would create a
serious usability and accessibility concern.
The correct distinction is not:
accessibility API versus ordinary API.
It is:
assistive computation versus externally consequential effectuation.
Ordinary assistive operations such as:
reading UI structure;
magnification;
screen narration;
focus navigation;
non-consequential interface assistance;
need not automatically be treated like high-risk agentic acts merely because they use
accessibility infrastructure.
However, when any pathway-accessibility or otherwise-causes:
a payment;
message send;
credential disclosure;
file export;
account modification;
external upload;
device-setting modification;
or another consequential act,
that consequence still requires finality.
The PCT itself treats accessibility as a governed path when it produces a consequential action
rather than treating the API name itself as the security boundary.
The preferred rule is:
Do not carve out an API. Classify the consequence.
A trusted assistive principal may also receive:
pre-authorized bounded capability envelopes;
local low-latency verification;
long-lived accessibility session context;
accessibility-priority availability;
simplified trusted confirmation appropriate to the user's needs.
That preserves accessibility without creating an "accessibility" label that malicious software
could use as a bypass.
Q18. Does the LAVR create a surveillance corpus by recording every
consequential user action?
It could if implemented as a centralized, indefinitely retained, identity-linked activity ledger.
That should not be the default implementation.
The LAVR's purpose is to establish proof of protected validation, not to recreate the user's
complete behavioral history.
The privacy-preserving design should minimize both content and linkability.
A receipt can contain commitments to:
Candidate Act digest;
validation result;
policy epoch;
nonce;
sink identity;
capability commitment;
without storing:
message contents;
file contents;
prompt text;
full recipient history;
complete user identity;
raw model inputs.
The PCT already supports:
local secure receipts;
compact protected state;
privacy-preserving proofs;
zero-knowledge proofs;
signed receipts;
ledger-anchored receipts;
and lower-assurance no-external-receipt variants.
Additional privacy controls should include:
local-first storage;
purpose-specific receipt domains;
retention limits;
rotating pseudonymous identifiers;
selective disclosure;
unlinkable or compartmentalized receipt chains where possible;
disclosure only upon authorized audit;
aggregation rather than raw per-event export;
deletion or expiration where the assurance model permits it.
The key distinction is:
Tamper evidence does not require universal observability.
A receipt can prove that finality was enforced without becoming a central log of everything
the user did.
Q19. Does the architecture remove user autonomy by making the device
owner unable to override their own hardware?
A high-assurance security architecture inevitably creates tension between:
device-owner control;
platform security;
enterprise policy;
regulatory obligations;
payment or credential assurance.
The answer should not be to pretend that all of these authorities are identical.
The architecture can separate policy layers.
For example:
mandatory protected integrity rules
+
regulated-domain requirements
+
enterprise policy
+
device-owner policy
+
per-act user intent
The owner should be able, where the deployment permits it, to:
inspect active policy identity;
revoke assistant authority;
select third-party assistants;
reset local capability state;
disable optional governance profiles;
change owner-controlled policies;
verify which policy bundle is active.
For developer, repair, research or modified-device modes, the system may permit an explicit
trust-state transition rather than silently pretending the original assurance remains intact.
For example:
owner unlocks protected platform state
v
device attestation state changes
v
owner retains control
v
high-assurance relying parties may choose not to trust that state
This preserves owner autonomy without falsely representing a modified environment as still
satisfying the original protected assurance profile.
The core principle is:
User control and external trust do not have to be identical properties. A user may be
allowed to alter their device while a regulated relying party may separately decide
whether that modified state satisfies its assurance requirements.
D. Standardisation and Deployment Objections and
Responses
Q20. Why is standardisation important if the execution-finality architecture is
implemented inside protected firmware, operating-system components, secure
processors, or device controllers?
A purely proprietary implementation may remain difficult for external parties to inspect,
compare, test, or verify across different platforms. Standardisation creates a common
technical layer through which execution-finality behavior can become interoperable,
testable, auditable, and independently verifiable.
The objective is not to standardise one vendor's internal hardware design. The objective is to
standardise the interfaces, invariants, evidence structures, and conformance behavior
required for protected execution finality.
A standards profile could define common elements such as:
Candidate Act representation;
canonical commitment format;
action-class taxonomy;
resource and destination binding;
Finality Sink identity;
Effectuation Boundary identity;
governance or authority epoch;
nonce and freshness requirements;
capability scope;
non-bearer verification requirements;
validation-evidence or LAVR format;
policy-bundle identity;
parity-conformance evidence;
revocation semantics;
cumulative-budget predicates;
degraded-mode requirements;
and sink-side verification behavior.
The central standards invariant would remain:
A consequential act may be prepared, requested, routed, or computed, but it does not
become externally effective until a designated Finality Sink verifies valid scoped
authority for that exact consequence.
Standardisation does not require identical hardware
Different implementations may use:
secure enclaves;
trusted execution environments;
secure elements;
hardware security modules;
protected microcontrollers;
protected hypervisor partitions;
trusted controllers;
confidential computing;
firmware-isolated components;
or distributed protected services.
The standard need not prescribe which substrate is used.
Instead, it can define the externally testable requirement:
Candidate Act
v
Non-Effective State
v
Protected Validation
v
Scoped Finality Authority
v
Finality Sink Verification
v
Effectuation
This allows different platforms to implement the architecture differently while preserving
interoperable security semantics.
Standardisation makes parity externally testable
This is particularly important where the architecture is used for interoperability between first-
party and third-party assistants.
A standardised parity profile could define that equivalent Candidate Acts are evaluated
according to equivalent technical predicate structures.
For example:
same action class
same resource class
same destination class
same risk class
same user-intent condition
same consequence boundary
v
equivalent finality requirements
A conformity test can then determine whether this invariant is actually enforced rather than
relying on the platform operator's statement that equivalent treatment exists.
Standardisation can also solve the policy-governance problem
A common profile may define:
policy-bundle digest format;
governance-epoch representation;
policy-update transparency;
co-signature or threshold-authorization mechanisms;
parity-profile identifiers;
external audit evidence;
and conformity-test requirements.
That makes it possible for a regulator, conformity-assessment body, enterprise, or relying
party to verify which governance profile a device actually enforced.
The standard therefore separates:
WHO IMPLEMENTS THE HARDWARE
from
WHAT SECURITY INVARIANT MUST BE PROVABLE
Standardisation also supports cross-platform AI agents
Without a common finality model, an AI assistant interacting with multiple operating systems
may encounter entirely different concepts of:
permission;
user intent;
capability;
tool authority;
finality;
destination binding;
and consequence verification.
A standard Candidate Act and Finality Sink model could allow an agent to request an
operation using a common semantic structure while each platform retains control over its
protected implementation.
For example:
Agent requests:
"send File X to Recipient Y"
v
Standard Candidate Act
v
Platform A
secure-controller implementation
Platform B
TEE implementation
Platform C
distributed protected implementation
v
same externally verifiable finality semantics
The standard therefore concerns execution authority semantics, not hardware uniformity.
Relevant standardisation domains
The architecture naturally intersects several existing standards areas rather than belonging
exclusively to one.
Potential technical domains include:
trusted execution and secure components;
platform security;
device attestation;
capability-based security;
AI-agent and tool-call governance;
operating-system interoperability;
telecommunications;
identity and credential systems;
payment and wallet security;
confidential computing;
privacy-preserving audit evidence;
and AI governance infrastructure.
Bodies working in areas such as GlobalPlatform, Trusted Computing Group, ITU-T,
3GPP, ETSI, ISO/IEC JTC 1, W3C, and relevant AI-agent or interoperability
standards initiatives could therefore encounter different layers of the architecture.
A single standard would not necessarily need to cover the entire system. The architecture can
be decomposed into interoperable profiles.
For example:
Profile 1
Candidate Act + capability format
Profile 2
Protected finality verification
Profile 3
Policy and parity attestation
Profile 4
AI-agent / tool-call finality
Profile 5
Privacy-preserving validation evidence
Profile 6
Telecom / network egress finality
Profile 7
Payment and wallet finality
The strategic value of standardisation is therefore broader than implementation uniformity:
It converts execution finality from a platform-specific security mechanism into a
common, independently testable infrastructure property.
Q21. Existing platforms already use secure processors, protected
confirmation, app-intent frameworks, hardware-backed keys, sandboxing,
entitlements, and isolated AI runtimes. What would need to be standardised
beyond those mechanisms?
Those mechanisms provide important building blocks, but they do not by themselves create a
common cross-platform definition of execution finality for an exact consequential act.
The standardisation opportunity is the ordered relationship among the components:
Candidate Act
v
explicit Non-Effective State
v
release-form commitment
v
protected predicate validation
v
protected validation evidence
v
scoped non-bearer execution authority
v
resource + destination + sink + boundary binding
v
Finality Sink verification against actual release state
v
authority consumption
v
effectuation
A standards profile could therefore define several properties that ordinary permission systems
do not necessarily define uniformly.
1. Computation is not execution authority
An AI model may generate:
a payment instruction;
email;
file export;
API invocation;
browser action;
tool call;
device command;
without that computation itself authorizing the consequence.
The standard would define a formal transition from:
PROPOSED / COMPUTED
to:
AUTHORIZED TO BECOME EFFECTIVE
2. Permission is not finality
A broad application entitlement or permission may establish that an application can use a
class of resource.
Execution finality asks a narrower question:
Is this exact act, against this exact resource and destination, currently authorized to
become effective?
That distinction can be standardised independently of existing permission frameworks.
3. Authority must remain act-scoped
Authority granted for:
File A -> Recipient X
must not automatically authorize:
File B -> Recipient X
or:
File A -> Recipient Y
or another downstream act generated by an agent.
Standardisation can define the mandatory scope fields used to prevent such expansion.
4. Capability possession alone must be insufficient
A finality capability may be transported through ordinary software, but copying or replaying
it must not by itself create authority.
The standard may require binding to:
Candidate Act;
requester;
resource;
destination;
nonce;
epoch;
Finality Sink;
and Effectuation Boundary.
5. Alternate APIs must not change finality requirements
The same consequence may be requested through:
public API;
private API;
app intent;
browser automation;
accessibility route;
IPC;
plug-in;
SDK;
cloud relay;
internal service.
The standards property is consequence-based:
Equivalent external consequences remain subject to equivalent finality requirements
regardless of the software route used to reach the boundary.
6. First-party and third-party parity becomes technically measurable
Standardisation can define equivalent-action test cases so that parity is not simply a policy
statement.
A conformity suite could submit equivalent first-party and third-party Candidate Acts and
compare:
predicate profile;
capability scope;
denial reasons at the protected level;
Finality Sink requirements;
policy-bundle identity.
This would make interoperability parity independently testable.
7. The first usable release boundary becomes a common architectural concept
The relevant enforcement point is not necessarily where the request originates.
It is:
the last point at which the artifact remains determinable and complete withholding
remains possible immediately before the consequence becomes usable.
A standard can define how implementations identify and attest that boundary for different
action classes.
8. Validation evidence becomes portable
A standardised LAVR or equivalent protected evidence format could allow an authorized
verifier to establish that:
the Candidate Act remained non-effective;
the correct policy profile was applied;
protected predicates passed;
scoped authority was issued;
the designated Finality Sink verified it;
and finality occurred under the expected governance epoch.
The verifier would not need access to the platform's proprietary internal implementation.
Standardisation Objective
The purpose is not to replace existing secure hardware, operating-system permissions,
protected confirmation systems, or application frameworks.
The purpose is to establish a common technical rule for when machine-generated intent
becomes externally effective authority.
The resulting standards abstraction is:
COMPUTATION
=
AUTHORITY
PERMISSION
=
FINALITY
CAPABILITY POSSESSION
=
EFFECTUATION
PROTECTED VALIDATION
+
EXACT ACT BINDING
+
FINALITY SINK VERIFICATION
=
AUTHORIZED CONSEQUENCE
A cross-platform standard built around that invariant could allow different device
ecosystems, AI assistants, applications, telecom systems, payment systems, and regulated
infrastructures to implement different internal mechanisms while still exposing the same
independently verifiable execution-finality semantics.
Q21. What is the answer when a platform vendor says, "We already have
secure hardware, protected confirmation, secure intent, app-intent controls,
hardware-backed keys, and isolated AI runtimes"?
The answer should not be that secure hardware itself is new.
Secure processors, trusted execution, protected confirmation, app intents, hardware-backed
keys, sandboxing, entitlement systems and isolated AI runtimes are existing building blocks.
The technical distinction to emphasize is the ordered execution-finality invariant across
generic consequential action classes.
The architecture is not merely:
secure hardware
+
permission
+
confirmation
It is:
Candidate Act
v
explicit Non-Effective State
v
release-form commitment
v
protected predicate validation
v
protected validation evidence
v
scoped non-bearer finality authority
v
binding to resource + destination + sink + boundary
v
Finality Sink independently verifies actual release state
v
authority consumption
v
effectuation
The distinction also includes:
computation does not itself create execution authority;
possession of the capability alone is insufficient;
authorization for one act does not expand to another act;
separate downstream consequential acts receive separate finality;
alternate APIs do not bypass consequence-level enforcement;
first-party internal routes remain subject to equivalent finality for equivalent
Candidate Acts;
the first usable release boundary, not an earlier policy check, controls final
effectuation;
protected validation evidence exists before or atomically with authority release.
The current PCT expressly distinguishes ordinary permissions, entitlements, API access, user
approval and software mediation from sink-side finality, and it closes first-party, alternate-
route, local-AI, cloud-assisted and bearer-token substitutions.
Accordingly, the response is:
Existing secure components may supply parts of the implementation. The relevant
technical question is whether those components collectively enforce the complete
Candidate Act -> Non-Effective State -> protected validation -> scoped finality
authority -> actual-release verification -> Finality Sink effectuation sequence for
generic consequential acts, including equivalent first-party and third-party paths.
The hardware is not the central distinction.
The distinction is the execution-authority architecture imposed across the consequence
boundary.
Consolidated Position
These additional objections add six requirements to the earlier five core invariants:
6. Policy itself must have protected provenance and, where neutrality matters,
independent verifiability.
7. Finality must be capable of reasoning over cumulative protected state, not only
isolated acts.
8. Declared purpose is a constraint label, not proof of semantic intent.
9. AI behavioral enforcement must target measurable runtime and action-level
invariants rather than deterministic model outputs.
10. Privacy, accessibility, user autonomy and availability are architectural
requirements, not afterthoughts.
11. Distributed finality prevents unauthorized sub-actions but does not automatically
guarantee rollback of already irreversible acts.
The complete architecture therefore becomes:
POLICY PROVENANCE / GOVERNANCE
v
CANDIDATE ACT
v
RELEASE-FORM COMMITMENT
v
NON-EFFECTIVE STATE
v
PER-ACT + CUMULATIVE PROTECTED PREDICATES
v
PED AUTHORITY VALIDATION
v
LAVR / PRIVACY-PRESERVING EVIDENCE
v
SCOPED NON-BEARER CAPABILITY
v
GOVERNED EGRESS SET
v
FINALITY SINK RE-DERIVES ACTUAL RELEASE STATE
v
MATCH + CURRENT BUDGET + CURRENT POLICY?
NO YES
v v
FAIL CLOSED CONSUME / ADVANCE
v
EFFECTUATE
v
MINIMAL PROTECTED RECEIPT
The resulting principle is:
No software component, policy author, agent, assistant, platform service, cached
permission, prior approval, alternate API, or possession of an authorization object
should by itself be sufficient to create an externally effective consequence. The exact
consequence must remain bound to protected authority, current protected state,
independently identifiable policy, and sink-side verification at the boundary where that
consequence actually becomes usable.
Additional Technical Objections and Responses
Q22. If applications already define actions through structured intent schemas,
why is a separate Candidate Act necessary?
Structured intent frameworks can define available application actions, required parameters,
entities, and data relationships. An intent therefore describes an executable application
capability.
A Candidate Act operates at a different layer. It represents the specific consequence
presently proposed for effectuation.
For example:
APP INTENT DEFINITION
SendMessage(
recipient,
content
)
This defines an action class.
A Candidate Act represents a particular execution:
THIS EXECUTION
recipient = X
actual final payload = H(...)
attachment = Y
requester = Agent A
destination = X
sink = MessageSendSink
boundary = B
epoch = E
nonce = N
The sequence is therefore:
Intent schema
v
Action invocation
v
Actual resource and destination resolved
v
Candidate Act
v
Release-form commitment
v
Protected finality
The standardisation objective is not to replace structured-intent frameworks. It is to establish
a common final execution-authority layer beneath or alongside those frameworks.
An intent answers:
What operation does the application expose?
A Candidate Act answers:
Is this exact instance of that operation, involving these exact resources and destinations,
authorized to become externally effective now?
Q23. How can a platform-level Candidate Act normalize the semantics of
thousands of unrelated applications?
A universal execution-finality layer does not need to understand the complete business
semantics of every application.
Application-specific semantics and consequence semantics can remain separate.
Applications may define operations such as:
PublishInvoice
SubmitMedicalForm
BookTrip
ApproveExpense
ShareAlbum
The execution-finality layer can instead operate on a smaller set of standardized consequence
primitives:
DATA_DISCLOSURE
NETWORK_TRANSMISSION
MESSAGE_SEND
PAYMENT_COMMIT
CREDENTIAL_RELEASE
IDENTITY_DISCLOSURE
STORAGE_COMMIT
EXTERNAL_API_INVOCATION
SENSOR_RELEASE
INTER_PROCESS_TRANSFER
DEVICE_SETTING_CHANGE
PHYSICAL_ACTUATION
PROTECTED_RENDER
An application-specific action can map to one or more consequence classes.
For example:
PublishInvoice
v
DATA_DISCLOSURE
+
NETWORK_TRANSMISSION
+
STORAGE_COMMIT
or:
BookTrip
v
CREDENTIAL_RELEASE
+
EXTERNAL_API_INVOCATION
+
PAYMENT_COMMIT
The application may provide the initial semantic mapping, but providing that mapping does
not create execution authority.
The actual consequence remains independently bound to machine-verifiable attributes such
as:
actual resource
actual release-form commitment
actual recipient
actual destination
actual amount
actual credential
actual network endpoint
actual Finality Sink
actual Effectuation Boundary
current epoch
fresh nonce
The Protected Execution Domain therefore does not need to understand the complete human
meaning of BookTrip.
It needs to determine:
Which protected consequence classes are about to become effective, and whether valid
authority exists for those consequences.
For an unmapped or novel consequential action, the architecture may:
require registration of a structured consequence schema;
require explicit action-class, resource, and destination mapping;
classify the act according to its downstream Effectuation Boundary;
require stronger trusted-user confirmation;
assign the operation to an unknown or high-risk consequence class;
or fail closed where the consequence cannot be safely classified.
This avoids both extremes:
trusting application-defined meaning as final authority
and
requiring the PED to become a universal application-semantic engine.
The source material already distinguishes application semantics from standardized
consequence semantics.
Q24. Does equivalent first-party and third-party treatment incorrectly assume
identical trust properties?
Equivalent treatment does not require identical identity, provenance, privilege, or attestation
evidence.
Different requesters may legitimately have:
different code provenance;
different sandbox privileges;
different protected entitlements;
different signing authority;
different hardware access;
different attestation mechanisms.
The relevant parity invariant is:
Equivalent externally consequential acts must face equivalent finality requirements,
while requester-specific trust evidence may legitimately differ.
For example:
FIRST-PARTY REQUEST
identity evidence A
+
resource X
+
destination Y
+
payment consequence
+
fresh user confirmation
+
Finality Sink verification
and:
THIRD-PARTY REQUEST
identity evidence B
+
resource X
+
destination Y
+
payment consequence
+
fresh user confirmation
+
Finality Sink verification
The identity evidence may differ.
The prohibited asymmetry is:
third-party equivalent consequence
-> finality required
first-party equivalent consequence
-> finality bypassed
The parity rule is therefore about the consequence-level security invariant, not about
forcing every requester to present identical credentials.
Q25. Does exposing Finality Sink functionality to third-party applications
create a privileged attack surface?
The application-facing interface does not need to expose protected internal mechanisms.
Applications need not directly manipulate:
PED keys;
secure counters;
hardware registers;
sink-controller state;
queue-enable material;
cryptographic unlock values;
protected memory;
or protected policy state.
The application-facing interface can remain abstract:
REQUEST CANDIDATE ACT
v
opaque platform mediation
v
protected validation
v
Finality Sink verification
v
success / denial
The capability itself may remain opaque to the requesting application.
An application or operating-system component may transport a capability without receiving
authority to:
mint it;
expand it;
reinterpret it;
modify it;
replay it outside its bound scope;
or force a Finality Sink to accept it.
Standardisation can therefore define:
Candidate Act semantics;
capability binding requirements;
Finality Sink verification behavior;
policy identity;
attestation;
evidence formats;
and conformance requirements,
without exposing privileged controller internals to third-party software.
Q26. How are application, model, runtime, or operating-system updates
handled without silently transferring old authority into a new software state?
Authority may be bound to:
application measurement;
code-signature state;
model identity;
runtime version;
governance epoch;
policy epoch;
security state.
An update may therefore invalidate existing act-specific authority.
For example:
OLD VERSION
app_measurement = A
epoch = 100
v
software update
v
NEW VERSION
app_measurement = B
epoch = 101
Capabilities issued under the old measured state should not silently migrate to the new state.
A version transition can instead follow:
old act-specific capability -> expires / invalid
new software state -> re-attested
stable user policy -> may remain subject to revalidation
new protected session -> established
new act-specific capability -> issued
Long-lived user preferences or policy configuration may survive an update where permitted.
Act-specific execution authority generally should not survive automatically.
This preserves the distinction between:
persistent policy
and
fresh authority to effectuate a specific consequence.
Q27. What happens when an operation begins on one device but becomes
effective on another?
Cross-device execution introduces another trust boundary.
Examples include:
phone request -> watch payment
tablet request -> laptop file send
headset request -> phone communication
cloud-generated request -> local device effectuation
A capability bound to Device A's protected state and Finality Sink should not automatically
become executable authority on Device B.
Two general models are possible.
Model 1: New Candidate Act at the receiving device
DEVICE A
Candidate Act A
v
protected authorization
v
delegation commitment
v
DEVICE B
receive delegated request
v
construct Candidate Act B
v
verify Device A provenance
v
validate Device B state
v
issue Device-B-bound capability
v
Device B Finality Sink
Model 2: Jointly authorized cross-device capability
A cross-device capability may be jointly bound to:
Device A identity;
Device B identity;
originating Candidate Act;
receiving Candidate Act;
destination;
action class;
participating sinks;
nonce;
governance epoch;
delegation scope.
The original capability must not become a freely transferable bearer credential merely
because the workflow crosses devices.
Device identity therefore becomes another load-bearing finality attribute.
Q28. What happens if the Finality Sink consumes authority and the device
crashes before the external consequence completes?
This is a crash-consistency problem.
For example:
capability verified
v
authority consumed
v
CRASH
v
did the consequence occur?
The reverse sequence is also possible:
external effect committed
v
CRASH
v
protected consumed-state not fully recorded
Execution finality therefore requires a crash-consistent protected commit state.
A representative state machine is:
ISSUED
v
ARMED
v
COMMITTING
v
EFFECT-COMMITTED
v
CONSUMED
The exact state machine depends on the consequence class.
Locally controlled consequences
For consequences under direct local control, protected authority consumption may be
atomically or crash-consistently coupled with the local effect.
Examples include:
storage commit;
protected-display release;
local credential release;
device-setting change;
actuator enablement;
secure transaction state.
The intended invariant is:
either
authority remains unused
AND
effect does not occur
or
authority is consumed
AND
local effect is committed
Intermediate states must be recoverable from protected state.
Networked consequences
Networked consequences introduce a different problem because local protected state cannot
always determine whether the remote party completed the operation.
Execution authority and proof of external completion must therefore remain distinct concepts.
Q29. Can the architecture guarantee exactly-once execution for networked
consequences?
Not universally.
Consider:
SEND transaction X
v
remote service executes X
v
ACK lost
v
local device does not know whether retry is safe
A retry could produce:
harmless retransmission;
duplicate message;
duplicate payment;
duplicate API operation;
duplicate external side effect.
Execution finality can provide:
single-use authority;
sink-local consumption;
replay resistance;
bounded retry authority;
transaction identifiers;
idempotency identifiers.
For example:
CandidateActID = X
ExternalTransactionID = X
A retry remains bound to:
the same Candidate Act;
same resource;
same destination;
same action class;
same transaction identity;
same sink;
same boundary;
same bounded retry policy.
Where the receiving protocol supports idempotency, repeated delivery can be recognized as
the same logical transaction rather than a newly authorized act.
The bounded architectural statement is:
Execution finality prevents uncontrolled replay or reuse of execution authority. Exactly-
once external effect additionally requires appropriate transaction or idempotency
semantics at the receiving system.
This distinction between authority consumption and external completion is already identified
in the source material.
Q30. Does release-form commitment create unacceptable power or latency
overhead for large files, video, audio, or continuous sensor streams?
It could if every large payload had to be copied into the Protected Execution Domain or
synchronously rehashed immediately before effectuation.
The preferred design keeps bulk payload processing outside the PED.
For large or streaming resources, a Finality Sink or protected boundary-adjacent component
may use:
incremental hashing;
hardware cryptographic acceleration;
DMA-integrated commitments;
Merkle commitments;
chunk commitments;
rolling commitments;
bounded stream descriptors.
For example:
VIDEO STREAM
stream identity
+
destination
+
frame / chunk sequence
+
rolling commitment root
+
maximum duration
+
maximum bytes
+
sink identity
+
boundary identity
The PED then operates on the compact commitment rather than the entire stream.
The security property is preserved because the sink derives the commitment from the actual
stream presented for release.
The computational model becomes:
bulk payload
v
boundary-side commitment generation
v
compact commitment
v
PED authority validation
v
sink-local verification
v
effectuation
The source material already identifies incremental hashing, DMA-integrated commitments,
Merkle commitments, chunk commitments, and bounded stream descriptors as relevant
mechanisms.
Q31. Can a digest of private information itself become a privacy leak?
Yes.
A conventional persistent content hash is not automatically privacy-preserving.
For low-entropy or predictable resources, an observer may be able to test candidate values
against the exposed digest.
Examples include:
short messages;
common forms;
known documents;
small categorical values;
predictable structured records.
Validation evidence therefore should not unnecessarily expose stable reusable content
fingerprints.
Possible commitment mechanisms include:
keyed commitments;
salted commitments;
HMACs;
per-session commitments;
ephemeral commitments;
pseudonymous resource identifiers;
selective-disclosure evidence;
zero-knowledge proof mechanisms where appropriate.
An external verifier may only need to establish:
authorized resource commitment
=
actual released resource commitment
without learning a globally reusable content fingerprint.
The privacy requirement is therefore:
Commitment equality should be verifiable without unnecessarily creating a persistent
cross-context identifier for the underlying content.
Q32. Could standardized device, policy, sink, and attestation identifiers
become a fingerprinting mechanism?
Yes.
A standards profile that routinely exposes:
device model
firmware version
PED version
policy bundle
sink topology
security patch level
hardware configuration
could create a powerful device fingerprint.
Standardisation should therefore distinguish:
conformance attestation
from
unique device identity.
A relying party may need to verify:
device satisfies Finality Profile X
without learning:
unique hardware identifier
exact device serial number
complete firmware topology
A privacy-preserving attestation design may therefore prove:
assurance profile >= required level
while minimizing disclosure of unique underlying device attributes.
The objective is to prove security properties, not necessarily to expose the device's complete
identity.
Q33. Does policy transparency require publishing security-sensitive internal
policy logic?
No.
Transparency does not require disclosure of every proprietary risk heuristic, dynamic anti-
abuse signal, fraud-detection rule, or internal detection threshold.
Externally verifiable information may be limited to:
policy identity;
policy version;
governance epoch;
mandatory parity profile;
applicable action classes;
mandatory finality invariants;
security-assurance level;
update history;
policy-bundle commitment.
A platform may retain confidential dynamic signals while still proving that:
third-party Candidate Act
and
equivalent first-party Candidate Act
were evaluated under
the same mandatory consequence-level
finality profile
The transparency objective is therefore:
verifiable policy provenance and mandatory invariant compliance
rather than publication of every internal decision rule.
Q34. Could a standardized execution-finality layer freeze platform
innovation?
A standard that dictates:
processor architecture;
exact kernel hooks;
exact controller topology;
exact cryptographic algorithms;
exact hardware module;
exact trusted-UI design;
exact internal API structure,
would be unnecessarily rigid.
The standard should instead define observable security invariants.
For example:
REQUIRED
Candidate Act remains non-effective
exact consequence commitment
fresh scoped authority
resource and destination binding
sink identity binding
boundary identity binding
replay resistance
sink-side verification
anti-bypass property
independently testable parity
Implementation may remain flexible:
POSSIBLE IMPLEMENTATIONS
TEE
secure enclave
secure element
protected controller
confidential VM
protected microcontroller
distributed protected service
future hardware architecture
The standard therefore defines what must remain true, not exactly how a platform must
implement it.
This allows hardware and operating-system architectures to evolve without changing the
finality invariant.
Q35. How can completeness of the Governed Egress Set be proven?
Declaring that every consequence-producing path contains a sink is not sufficient.
A modern platform may include:
CPU;
GPU;
NPU;
DMA engines;
display processors;
secure processors;
baseband or modem paths;
Wi-Fi controllers;
Bluetooth controllers;
sensor hubs;
storage controllers;
peripheral processors;
firmware services;
private controller paths.
An omitted path may defeat complete mediation.
The stronger standardisation mechanism is an attested Finality Boundary Manifest.
For each governed consequence class, the platform maintains a measured and versioned
description of the boundaries capable of externalizing that consequence.
For example:
NETWORK_EGRESS
-> cellular modem sink
-> Wi-Fi sink
-> Bluetooth sink
FILE_EXTERNALIZATION
-> file-provider sink
-> storage/export sink
DISPLAY_RELEASE
-> compositor sink
-> protected display sink
SENSOR_DISCLOSURE
-> sensor-HAL sink
-> protected DMA sink
PAYMENT_COMMIT
-> protected transaction-finalization sink
The Finality Boundary Manifest should be:
measured;
versioned;
signed or attested;
bound to the hardware and firmware configuration;
associated with the active Finality Sink topology;
updated after relevant topology changes;
independently testable through conformity procedures.
An unregistered change to a:
GPU path;
DMA route;
modem;
controller;
firmware component;
coprocessor;
or other externalization route
should change the measured platform state and invalidate the previous finality-conformance
attestation until the new topology has been evaluated.
A conformity regime can then test two properties:
MANIFEST INTEGRITY
+
BEHAVIORAL COMPLETENESS
Manifest integrity establishes that the declared sink topology corresponds to the measured
implementation.
Behavioral completeness establishes that governed consequences cannot be externalized
through undeclared or unverified routes.
The source text identifies the Finality Boundary Manifest as the mechanism for moving from
an asserted no-bypass property to an independently testable one.
Q36. What happens to long-running background agents when there is no
fresh user interaction?
Requiring fresh user confirmation for every background act would undermine legitimate
automation.
Allowing a historical confirmation to authorize unlimited future actions would undermine
execution finality.
The solution is a bounded durable intent lease.
For example:
AUTHORIZED AUTOMATION
Send daily report
to Recipient X
once per day
for 30 days
maximum one attachment
from Folder Y
The protected lease may bind:
action class;
resource scope;
destination;
maximum frequency;
maximum execution count;
validity period;
expiration;
revocation state;
sink identity;
boundary identity;
cumulative quota;
governance epoch.
Each actual execution still produces a fresh Candidate Act.
The persistent object represents:
durable user intent
while each individual execution still requires:
fresh act-specific authority.
The sequence becomes:
durable intent lease
v
scheduled trigger
v
fresh Candidate Act
v
current protected-state validation
v
fresh scoped capability
v
Finality Sink
v
effectuation
The principle is:
Durable intent may persist; execution authority remains fresh, bounded, and act-
specific.
The bounded durable-intent model is described in the source material as a way to preserve
automation without converting old user approval into unlimited authority.
Q37. Could validation evidence conflict with stateless or privacy-preserving
AI processing?
Only if validation evidence is interpreted as requiring a centralized, permanent record of
every AI-processing event.
Execution-finality evidence does not need to contain:
plaintext prompt content;
complete message content;
complete file contents;
full model inputs;
persistent recipient histories;
reusable content fingerprints.
A minimal-evidence mode may retain only compact protected state such as:
counter advanced
+
governance epoch
+
policy commitment
+
anonymous or unlinkable commitment root
More detailed content-dependent state may disappear after finality where the assurance
model permits it.
Where externally auditable evidence is required, the record can contain protected
commitments rather than plaintext.
The distinction is:
proof that validation occurred
does not require
retention of the underlying personal data.
Validation evidence can therefore be:
local-first;
compact;
selectively disclosed;
purpose-specific;
retention-limited;
compartmentalized;
cryptographically committed;
and privacy-preserving.
The source material similarly distinguishes minimal protected evidence from indefinite
retention of detailed AI-processing information.
Consolidated Standardisation Position
These objections resolve into several cross-platform requirements:
1. Structured intents and application APIs define available operations; Candidate Acts
define exact instances of consequential execution.
2. Application-specific semantics are normalized into a bounded set of consequence
primitives rather than interpreted comprehensively inside the PED.
3. Equivalent consequences receive equivalent finality requirements even where
requester-specific identity evidence differs.
4. Protected internals remain opaque; standardisation focuses on semantics, binding,
evidence, attestation, and conformity.
5. Software and model updates create explicit authority-version transitions rather than
silently inheriting old act-specific authority.
6. Cross-device execution requires receiving-device finality or explicitly bounded joint
authorization.
7. Crash consistency is handled through protected commit states, while exactly-once
remote execution remains dependent on receiving-protocol semantics.
8. Large and streaming artifacts use boundary-side incremental commitments rather
than bulk PED processing.
9. Content commitments and attestation should be privacy-preserving rather than
globally linkable identifiers.
10. Standards should define observable execution-finality invariants rather than
prescribing platform implementation topology.
11. Completeness of protected egress is established through an attested Finality
Boundary Manifest and conformity testing.
12. Background automation uses durable intent but fresh act-specific execution
authority.
13. Validation evidence proves protected finality without requiring permanent retention
of the underlying personal content.
Additional Technical Objections and Responses
Q38. How can completeness of the Governed Egress Set be proven?
Defining every consequence-producing boundary as a Finality Sink, or as structurally
downstream of one, addresses bypass conceptually. It does not by itself prove that every
possible hardware and software egress path has actually been identified.
A modern computing platform may contain multiple independent or semi-independent
consequence-producing components, including:
CPU
GPU
NPU
DMA engine
baseband / modem
Wi-Fi controller
Bluetooth controller
display processor
sensor hub
storage controller
secure processor
peripheral processor
private framework
coprocessor
firmware-controlled path
A single omitted path may defeat complete mediation.
The stronger approach is an attested Finality Boundary Manifest.
For each governed consequence class, the platform maintains a measured and versioned
description of all hardware, firmware, protected-software, and controller boundaries capable
of externalizing that class.
For example:
NETWORK_EGRESS
-> cellular modem / baseband
-> Wi-Fi controller
-> Bluetooth controller
-> network egress controller
DISPLAY_RELEASE
-> GPU output path
-> compositor
-> display controller
-> external-display controller
DATA_TRANSFER
-> IPC
-> shared memory
-> DMA
-> file-provider boundary
-> storage controller
SENSOR_RELEASE
-> sensor hub
-> DMA path
-> HAL delivery boundary
-> external transmission path
PHYSICAL_ACTUATION
-> actuator controller
-> device-control coprocessor
-> motor / haptic / radio control boundary
The Finality Boundary Manifest should be:
measured;
versioned;
signed or attested;
bound to the hardware and firmware configuration;
associated with the active Finality Sink topology;
updated when firmware, controller configuration, or hardware state changes;
and independently testable through conformity procedures.
The conformance rule is:
Every component capable of externalizing a governed consequence must either perform
Finality Sink verification itself or be structurally downstream of a protected boundary
that has already performed that verification.
A new or modified GPU, DMA path, modem route, firmware module, private controller, or
coprocessor capable of externalization should change the measured platform state.
That change invalidates the previous finality-conformance attestation until the new topology
has been measured, classified, and incorporated into the Finality Boundary Manifest.
This produces two distinct conformity properties:
MANIFEST INTEGRITY
+
BEHAVIORAL COMPLETENESS
Manifest integrity proves that the declared Finality Sink topology corresponds to the
measured platform configuration.
Behavioral completeness tests whether each declared consequence class can actually be
externalized only through the stated governed boundaries.
The anti-bypass claim therefore does not rest on the statement:
"Every API has been intercepted."
It rests on the stronger property:
Every physical or logical boundary capable of producing the governed consequence is
part of an attested egress topology and lacks independent effectuation authority outside
that topology.
This converts Governed Egress Set completeness from an architectural assertion into a
measurable and testable platform property.
Q39. What happens if a crash, power loss, network failure, or retry occurs
between authorization consumption and external effectuation?
Execution authority and external completion are separate problems.
A Finality Sink may successfully verify a capability and consume protected authority, but the
device may fail before the consequence becomes externally effective.
For example:
capability verified
v
authority consumed
v
CRASH
v
was the external act completed?
The reverse order can also occur:
external effect committed
v
CRASH
v
protected consumed-state not fully recorded
This is different from partial completion of a multi-step workflow.
It is a crash-consistency problem inside the finality transaction itself.
A protected Finality Sink should therefore implement an explicit commit state machine.
For example:
ISSUED
v
ARMED
v
COMMITTING
v
EFFECT-COMMITTED
v
CONSUMED
or an equivalent protected sequence.
The exact sequence depends on the consequence class.
Locally controlled consequences
For consequences under direct local control, authority consumption may be coupled closely
or atomically with the relevant commit operation.
Examples include:
protected storage commit;
secure-element transaction state;
protected display release;
local credential release;
actuator enablement;
local device-setting modification.
Where hardware permits, protected state advancement and effectuation should form one
atomic or crash-consistent transition.
The required property is:
either:
authority remains unused
AND
effect does not occur
or:
authority is consumed
AND
local effect is committed
Intermediate ambiguous states should be recoverable from protected state.
Networked consequences
For external networked systems, the device cannot universally determine whether the remote
consequence occurred.
For example:
SEND transaction X
v
remote system executes X
v
ACK lost
v
device cannot determine whether X should be retried
Execution-finality architecture therefore should not claim universal exactly-once external
semantics.
The correct distinction is:
The architecture can enforce single-use or bounded-retry execution authority. Exactly-
once external effect additionally requires cooperation from the receiving protocol or
service.
A stable Candidate Act identifier may be mapped to an external idempotency or transaction
identifier:
CandidateActID = X
ExternalTransactionID = X
Any retry must remain bound to:
the same Candidate Act;
the same resource;
the same destination;
the same requester;
the same action class;
the same transaction identity;
the same Finality Sink;
the same Effectuation Boundary;
and a bounded retry policy.
For example:
Candidate Act X
v
Attempt 1
v
ACK unavailable
v
Retry authority for X only
v
Attempt 2 carrying same transaction ID X
The receiving system, where it supports idempotency, can recognize that the second request
represents the same logical transaction rather than a new authorized act.
Authority consumption and external completion must remain distinct
The architecture should therefore track two different properties:
AUTHORITY STATE
Did the protected system permit this act?
EXTERNAL COMPLETION STATE
Did the receiving system actually complete it?
The first can be protected locally.
The second may require:
protocol acknowledgement;
remote transaction state;
idempotency support;
settlement confirmation;
application-level completion evidence;
or equivalent external cooperation.
A lost acknowledgement must not automatically create a fresh unrestricted capability.
Likewise, a retry should not become authority for a new resource, destination, amount, or
operation.
The bounded statement is:
Execution finality prevents uncontrolled replay or reuse of execution authority; exactly-
once external execution is guaranteed only where the consequence-producing protocol
also provides appropriate transaction or idempotency semantics.
Q40. How can a generic execution-finality layer govern arbitrary application
actions without trusting application-defined meaning or becoming a universal
semantic engine?
A generic execution-finality layer does not need to understand the complete business
meaning of every application operation.
The architecture should separate:
application-specific semantics
from
standard consequence semantics.
An application may define operations such as:
BookTrip
PublishInvoice
ApproveExpense
SubmitMedicalClaim
ShareAlbum
SignContract
Those names and their business meaning remain application-specific.
The execution-finality layer instead works with a smaller set of standardized consequential
primitives such as:
DATA_DISCLOSURE
NETWORK_TRANSMISSION
MESSAGE_SEND
PAYMENT_COMMIT
CREDENTIAL_RELEASE
IDENTITY_DISCLOSURE
STORAGE_COMMIT
EXTERNAL_API_INVOCATION
SENSOR_RELEASE
DEVICE_SETTING_CHANGE
PHYSICAL_ACTUATION
PROTECTED_RENDER
INTER_PROCESS_TRANSFER
An application-specific operation may map to one or more consequence primitives.
For example:
PublishInvoice
v
DATA_DISCLOSURE
+
NETWORK_TRANSMISSION
+
STORAGE_COMMIT
Another example:
BookTrip
v
CREDENTIAL_RELEASE
+
EXTERNAL_API_INVOCATION
+
PAYMENT_COMMIT
And:
ShareAlbum
v
DATA_DISCLOSURE
+
NETWORK_TRANSMISSION
+
RECIPIENT_BINDING
The application may supply the initial mapping, but supplying a mapping does not create
execution authority.
The mapping is only the starting point for identifying the consequence classes that must be
governed.
The actual effectuation path still binds machine-verifiable attributes such as:
actual resource
actual release-form commitment
actual recipient
actual destination
actual amount
actual credential
actual external endpoint
actual Finality Sink
actual Effectuation Boundary
current epoch
fresh nonce
The Finality Sink then verifies the real consequence at the boundary where it can become
effective.
The architecture therefore does not need to determine:
"What does BookTrip mean philosophically or commercially?"
It needs to determine:
"Which standardized consequential primitives will become effective if this operation
completes, and does valid protected authority exist for each required consequence?"
Structured consequence schema
Applications, operating-system frameworks, or standards-defined interfaces may expose a
structured consequence schema.
For example:
APPLICATION ACTION:
BookTrip
CONSEQUENCES:
EXTERNAL_API_INVOCATION
CREDENTIAL_RELEASE
PAYMENT_COMMIT
BOUND ATTRIBUTES:
travel_provider = X
passenger_record = Y
amount <= Z
payment_destination = P
The semantic mapping may be application-provided, framework-provided, standardized, or
derived from system-level interfaces.
But load-bearing release attributes should still be independently verified at their relevant
Finality Sinks.
Unknown or novel action classes
When a new operation cannot be mapped safely to a known consequence class, the
architecture should not silently treat it as harmless.
Possible responses include:
require registration of a structured consequence schema;
require explicit resource, destination, and action-class mapping;
classify according to the downstream Effectuation Boundary;
require stronger trusted-user confirmation;
place the act into a higher-risk unknown-action class;
or fail closed where a consequential operation cannot be reliably classified.
A useful default rule is:
Unknown application meaning does not imply unknown technical consequence.
Even if the system does not understand the business semantics of PublishMedicalAnalysis,
it can still recognize that the operation is about to:
read protected file
v
serialize data
v
transmit to external endpoint
and govern those concrete consequences.
The PED remains small
This separation also prevents semantic normalization from turning the Protected Execution
Domain into an enormous policy engine.
The PED does not need:
a dictionary of every application command;
natural-language understanding of every business operation;
full application logic;
arbitrary workflow interpretation.
It needs a bounded representation of:
consequence class;
protected resource;
destination;
requester;
authority scope;
policy state;
user-intent state where required;
sink;
boundary;
freshness;
cumulative state where applicable.
The architecture therefore scales through a two-layer model:
APPLICATION SEMANTICS
v
structured mapping
v
STANDARD CONSEQUENCE PRIMITIVES
v
exact Candidate Act
v
protected authority
v
actual Finality Sink
This avoids both undesirable extremes:
TRUST APPLICATION MEANING COMPLETELY
and
MAKE THE PED UNDERSTAND EVERY APPLICATION
The governing principle is:
Applications define what their operations mean at the application layer; execution
finality governs the concrete consequence primitives through which those operations
become externally effective.
Consolidated Technical Position
These three objections correspond to three different completeness properties.
Hardware completeness
Can every consequence-producing route be identified and proven to remain inside the
protected egress topology?
Addressed through:
Governed Egress Set + attested Finality Boundary Manifest + conformity testing.
Transactional completeness
Can execution authority remain correct across crashes, retries, and uncertain remote
completion?
Addressed through:
crash-consistent sink state + single-use/bounded-retry authority + external idempotency
where supported.
Semantic completeness
Can arbitrary application operations be governed without requiring complete
understanding of arbitrary application meaning?
Addressed through:
application-specific semantics -> standardized consequence primitives -> exact
boundary verification.
Together:
APPLICATION ACTION
v
CONSEQUENCE NORMALIZATION
v
CANDIDATE ACT
v
RELEASE-FORM COMMITMENT
v
PROTECTED AUTHORITY
v
ATTESTED GOVERNED EGRESS SET
v
CRASH-CONSISTENT FINALITY SINK
v
EXTERNAL EFFECT
The combined invariant is:
Every externally consequential operation must be reducible to one or more machine-
verifiable consequence classes, every technical route capable of externalizing those
consequences must belong to an attested governed egress topology, and execution
authority must remain bounded and crash-consistent until the corresponding Finality
Sink controls the actual release.
Security Considerations
This document is primarily concerned with security architecture.
Security considerations include compromised applications or AI
assistants, replay, substitution, unauthorized redirection, stale or
revoked authority, alternate egress paths, and failure to verify
authority at the first usable release boundary. The architecture
described in this document uses fail-closed verification and scoped
execution authority to address these classes of risk. It does not
claim security after compromise of the trusted hardware root,
protected execution domain, or cryptographic root of trust.
IANA Considerations
This document has no IANA actions.
Author's Address
Sangam Das
Independent Inventor
Balasore, Odisha
India
Email: info@sangamdas.com