Description

Other

The DMA can require AI interoperability, but interoperability alone does not determine when a third-party AI is authorized to cause a real-world effect. My architecture addresses that missing execution-finality boundary.

How Existing Security and Interoperability Approaches Differ from the Execution-Finality Architecture

The approaches commonly proposed for secure AI interoperability—including sandboxed cross-app communication, standardized App Intents APIs, trusted operating-system brokers, confidential computing, OAuth/API authorization, human confirmation, static IAM/policy engines, and post-hoc monitoring—address important parts of the security problem.

They primarily govern:

• what information may be accessed;

• which interfaces may be invoked;

• which principal or application is authenticated;

• which general permissions or scopes have been granted;

• where computation takes place;

• whether a human has approved a displayed request; or

• whether suspicious activity can subsequently be detected.

The Execution-Finality architecture addresses a different and later security boundary:

Whether a particular instantiated AI-generated or AI-selected Candidate Act is authorized to cross from a Non-Effective State into an externally effective consequence.

Its central distinction is therefore not merely between authorized and unauthorized software.

It is between:

permission to participate in a process

and

authority for this particular act to become effective.

1. Sandboxed Cross-App Communication

A sandboxed intent architecture controls what information an AI system can access and isolates the AI from the underlying application database or operating-system resources.

Its principal security question is:

“What data may this AI system access?”

For example, a third-party assistant requesting information from an email application may be prevented from directly browsing the application's complete database. An operating-system broker may instead return only the specific information required for the request.

This substantially reduces unnecessary data exposure.

The Execution-Finality architecture addresses a separate question:

“After the AI system has lawfully obtained the required information, what authorizes this specific proposed action to become externally effective?”

Permission to retrieve a flight-confirmation email does not automatically establish authority to:

• forward the email;

• purchase another ticket;

• cancel the reservation;

• modify the itinerary;

• make a payment;

• disclose the information to another recipient; or

• invoke another application using information derived from the email.

Sandboxing therefore principally provides:

access isolation.

Execution Finality principally provides:

effectuation control.

The two mechanisms can operate together.

A sandbox may determine what information enters an AI execution environment, while an Execution-Finality mechanism determines whether an act produced from that information may leave the environment as an externally effective consequence.

2. Expanded App Intents / Universal AI API

A standardized App Intents or universal AI API architecture provides an interface through which multiple assistants can request application or operating-system functionality.

Its principal question is:

“Through which standardized interface may an AI system request an operation?”

For example, a platform might expose operations conceptually equivalent to:

SendMessage()

CreateCalendarEvent()

OpenDocument()

MakePayment()

or:

ControlDevice()

Such an interface can be important for interoperability because competing assistants can be given access to common functions without receiving unrestricted access to application internals.

However, availability of the interface does not by itself determine whether a particular invocation should become effective.

The Execution-Finality architecture therefore introduces a later question:

“What narrowly scoped authority permits this particular requested operation to cross the final execution boundary?”

Execution authority may be bound to attributes including:

• requesting AI or application identity;

• specific operation;

• user-authorized purpose;

• resource;

• recipient or destination;

• content or output scope;

• runtime state;

• policy state;

• security epoch;

• revocation state;

• relevant execution context; and

• the Candidate Act being authorized.

A generalized API therefore answers:

what operation can be requested.

Execution Finality answers:

whether this particular instantiated operation is permitted to take effect.

Accordingly:

An API enables interoperability. Execution Finality governs effectuation.

3. Trusted System Agent / Operating-System Broker

A trusted system-agent architecture places the operating system between a third-party AI system and protected applications or resources.

The resulting structure may resemble:

Third-Party AI → OS Broker → Application

The operating system can:

• authenticate the requesting application;

• enforce permissions;

• retrieve protected information;

• sanitize data;

• mediate application calls;

• route requests; and

• apply platform policy.

This provides a substantial improvement over unrestricted cross-application access.

The Execution-Finality architecture nevertheless introduces a further separation:

Mediation authority is not necessarily final execution authority.

A broker may determine that an operation appears permissible, while the eventual effectuation boundary independently determines whether the actual operation presented for execution still corresponds to the validated operation.

The operating system may participate in protected validation and establishment of constrained execution authority without transferring a generally reusable privilege to the requesting AI.

In applicable implementations, that authority may take the form of an App-Scoped Fractional Capability, Execution Handle, or comparable bounded non-bearer authority associated with protected validation state and the Candidate Act.

Conceptually:

Third-Party AI

→ Candidate Act

→ OS-mediated protected validation

→ protected validation evidence / LAVR

→ scoped execution authority

→ application prepares operation

→ Device-Side Finality Sink verification

→ external effect.

The requesting AI does not need to possess a freely reusable credential capable of being:

• exported;

• independently replayed;

• redirected;

• transferred to another execution path; or

• reused for a materially different operation.

The critical distinction is therefore:

The operating system is not merely a traffic controller. It can participate in establishing constrained execution authority whose correspondence to the actual act is still verified at the final effectuation boundary.

4. Confidential Computing / Private Cloud Compute

Confidential computing primarily protects the confidentiality and integrity of computation.

It addresses questions such as:

“Can sensitive data and AI workloads be processed without unnecessarily exposing them to the cloud operator, host environment, or other parties?”

Trusted execution environments, protected memory, attested workloads, encrypted transport, and confidential-cloud architectures can substantially reduce risks associated with remote AI processing.

However, trustworthy computation does not automatically establish trustworthy effectuation.

A securely executed AI workload could produce an instruction such as:

Transfer ₹50,000 to Account X.

The fact that:

• the model ran inside trusted hardware;

• the workload was attested;

• the input remained confidential; and

• the output was protected from tampering

does not by itself determine whether the transaction should actually occur.

Execution Finality therefore addresses a different question:

“Even when the computation is confidential and technically trustworthy, is its resulting Candidate Act authorized to affect the external world?”

Accordingly:

Confidential computing protects processing.

Execution Finality controls effectuation.

The two approaches are complementary.

Confidential computing may protect the environment in which a Candidate Act is generated or evaluated, while Execution Finality governs the boundary at which that Candidate Act becomes externally effective.

5. OAuth, Bearer Tokens, Scoped API Authorization, and Capability Credentials

OAuth and comparable API authorization mechanisms are among the most important comparisons because modern software commonly expresses delegated authority through access tokens, scopes, capabilities, or session credentials.

A conventional authorization model may grant a scope such as:

messages.send

or conceptual permission to invoke:

SendMessage()

The authorization server determines that a client has permission to invoke a class of operations within a defined scope.

This is extremely useful for API security.

However, a scope such as:

messages.send

does not necessarily mean:

“Send exactly this message, containing exactly this authorized content, to exactly this recipient, under exactly this runtime and policy state, one time only.”

The distinction can therefore be expressed simply:

A valid OAuth scope for SendMessage() may be necessary, but it is not necessarily sufficient to authorize this particular SendMessage() act.

Many access tokens are bearer credentials: possession of the token is sufficient to exercise the authority represented by it.

Modern OAuth deployments can also use sender-constrained mechanisms such as mutual TLS or proof-of-possession techniques. Accordingly, the distinction between OAuth and Execution Finality should not depend solely on whether a token is technically a bearer token.

The deeper distinction is scope granularity and act binding.

A conventional authorization credential commonly establishes that:

Client A may perform operation class B on resource class C during validity interval D.

Execution-Finality authority is intended to establish something closer to:

this validated Candidate Act, with these specific load-bearing attributes, may cross this particular finality boundary under the current protected state.

Accordingly, relevant execution authority may be bound to:

• the Candidate Act or canonical representation thereof;

• operation;

• identity;

• purpose;

• resource;

• recipient;

• destination;

• output scope;

• runtime state;

• security or policy epoch;

• revocation state; and

• other load-bearing execution attributes.

The authority may further be designed as non-bearer: mere possession of a serialized value does not independently provide the ability to exercise the authority.

It can additionally be:

• non-exportable;

• context-bound;

• single-use or consumption-controlled;

• anti-replay protected;

• sink-bound; and

• unusable for a materially different Candidate Act.

This produces a fundamental distinction:

OAuth/API authorization:

“This principal is permitted to invoke this category of API operation.”

Execution Finality:

“This particular validated act is eligible to cross this final execution boundary.”

Execution Finality therefore does not need to replace OAuth.

OAuth can authenticate and authorize access to the service.

Execution Finality can independently determine whether the resulting instantiated act may become effective.

6. Human-in-the-Loop Confirmation Dialogs

Human confirmation is currently one of the most common controls used for consequential agentic operations.

Before an AI system:

• sends an email;

• purchases an item;

• executes code;

• deletes data;

• transfers funds; or

• invokes a sensitive tool,

the interface may display:

“Are you sure?”

or:

“Approve this action.”

Human confirmation is valuable and may be appropriate for many consequential actions.

However, a confirmation dialog principally establishes that a user approved a representation of an intended operation presented through an interface.

It does not inherently establish that the operation ultimately reaching the execution boundary is cryptographically or technically identical to the operation that was represented to the user.

Potential failure modes can include:

• misleading or incomplete representations;

• prompt injection influencing the proposed operation;

• substitution after confirmation;

• destination changes;

• content changes;

• time-of-check/time-of-use differences;

• UI-redress or overlay attacks;

• compromised accessibility or automation mechanisms;

• confirmation of summarized content differing from actual content; or

• alternate execution paths bypassing the expected confirmation flow.

The Execution-Finality architecture therefore does not treat the confirmation interface itself as the final security boundary.

Human approval may instead become one input to protected validation.

The relevant protected validation evidence can commit to the load-bearing attributes of the Candidate Act, after which the Finality Sink verifies whether the actual operation presented for effectuation corresponds to the authorized state.

In hardware-rooted embodiments, the final gate may be implemented within or anchored to a protected execution environment inaccessible to ordinary application logic.

The distinction is therefore:

Human confirmation:

“The user approved the operation as represented.”

Execution Finality:

“The operation actually presented for effectuation still corresponds to the protected authorization established for the Candidate Act.”

This allows human approval to remain valuable without making the UI dialog itself the ultimate enforcement mechanism.

LAVR and Human Confirmation

Where a LAVR — protected validation record or commitment — is used, it should not be understood merely as a conventional post-hoc activity log.

It can represent protected evidence that the required validation occurred for the relevant Candidate Act before, or atomically with, establishment of execution authority.

The Finality Sink can then verify the correspondence between:

the validated Candidate Act

and

the act actually presented for effectuation.

This is materially different from simply recording after execution that an application reported having received user approval.

7. Static IAM and Policy Engines

Identity and Access Management systems and policy engines—including role-based access control, attribute-based access control, cloud IAM systems, and policy engines such as OPA—provide sophisticated mechanisms for deciding whether a principal may access a resource or invoke an operation.

A simplified authorization rule may evaluate:

principal × role × resource × requested operation × policy

and return:

ALLOW

or:

DENY.

These mechanisms are essential infrastructure.

The Execution-Finality distinction arises because authorization of a request is not necessarily identical to authorization of the eventual instantiated external effect.

A policy engine may correctly determine:

“Application A may send email.”

or:

“Agent B may invoke payment API C for transactions below threshold D.”

Execution Finality can additionally bind authority to the specific instantiated Candidate Act, including relevant dynamic attributes such as:

• exact destination;

• exact resource;

• requested effect;

• current runtime;

• security epoch;

• policy epoch;

• revocation state;

• output scope;

• validated content attributes; and

• final execution context.

This becomes particularly relevant when state changes between initial authorization and final execution.

For example:

1. a Candidate Act is validated;

2. organizational policy changes;

3. a credential is revoked;

4. the destination changes;

5. the operation is replayed; and

6. execution is attempted under the earlier authorization.

A conventional IAM system may also be configured to re-evaluate policy and can implement sophisticated contextual restrictions. The distinction should therefore not be framed as an absolute inability of IAM systems to address such conditions.

Rather, Execution Finality makes act-specific protected state and final-boundary verification a first-class architectural requirement rather than relying solely on upstream request authorization.

Accordingly:

IAM/policy engines determine whether a principal or request satisfies policy.

Execution Finality determines whether the particular Candidate Act reaching the finality boundary still satisfies the protected authority established for its effectuation.

8. Post-Hoc Monitoring, SIEM, Audit Logging, and Anomaly Detection

Monitoring systems provide another important security layer.

SIEM platforms, behavioral analytics, anomaly-detection systems, audit trails, fraud-detection systems, and security logs can identify suspicious behavior such as:

• unusual API calls;

• unexpected destinations;

• abnormal transaction volumes;

• unauthorized access patterns;

• anomalous agent behavior; or

• policy violations.

However, many such mechanisms operate during or after execution.

They may answer:

“What happened?”

or:

“Does this completed or ongoing activity look suspicious?”

Execution Finality is principally concerned with another question:

“May this act become effective at all?”

The architecture therefore places enforcement before the protected effectuation boundary.

Where mandatory conditions cannot be established, verification fails, protected state is inconsistent, or the proposed operation differs materially from the validated Candidate Act, the architecture can operate on a fail-closed basis.

This produces the distinction:

Monitoring and audit:

detect, reconstruct, investigate, or respond.

Execution Finality:

prevent unauthorized effectuation before the protected consequence is released.

The mechanisms are complementary.

Execution-Finality evidence can subsequently improve auditability, but auditability is not the architecture's primary enforcement mechanism.

The Fundamental Architectural Difference

The conventional approaches predominantly protect different portions of the path leading toward an external action:

User

↓

AI Assistant

↓

authentication / OAuth / permissions

↓

sandbox / App Intent API

↓

OS broker / IAM / policy evaluation

↓

confidential or protected computation

↓

human confirmation where required

↓

proposed operation

The Execution-Finality architecture introduces an additional architectural boundary:

proposed operation / Candidate Act

↓

Non-Effective State

↓

protected validation

↓

protected validation evidence / LAVR

↓

bounded execution authority

↓

Finality Sink reconstruction or verification

↓

authorized externally effective operation

The architecture therefore distinguishes concepts that should not automatically be treated as equivalent:

Access is not authority.

Authentication is not execution authority.

API permission is not act-specific execution authority.

Computation is not authority.

Human confirmation is not by itself proof that the same act was executed.

Upstream authorization is not necessarily final-boundary authorization.

Logging an action is not equivalent to preventing an unauthorized action.

A Candidate Act may therefore remain in a Non-Effective State even after:

• the user has authenticated;

• the AI application has authenticated;

• OAuth authorization has succeeded;

• the relevant API scope is valid;

• the application has obtained permitted information;

• an upstream policy engine has returned ALLOW;

• confidential computation has completed;

• a human has approved a displayed operation; and

• the application has prepared the requested action.

Those conditions can all be valid while the Candidate Act remains technically unable to produce its protected external effect.

Only after the required protected validation and verification of the associated scoped execution authority at the relevant Finality Sink does the Candidate Act become eligible for effectuation.

Illustrative Example

Consider the instruction:

“Send my flight itinerary to Alice.”

A conventional interoperable architecture could operate as follows:

AI Assistant

↓

OAuth / application authorization succeeds

↓

Mail access permission succeeds

↓

operating system retrieves itinerary

↓

AI invokes SendMessage()

↓

user sees “Send this message?” and approves

↓

Mail submits operation

↓

message is sent

Each security mechanism in that chain may work correctly.

Nevertheless, a remaining question exists:

Does the actual message being released correspond to the specific operation that was validated and authorized?

An Execution-Finality implementation can instead operate as follows:

AI Assistant

↓

proposes Candidate Act:

“Send this itinerary to Alice”

↓

Candidate Act remains in Non-Effective State

↓

operating system / protected validation environment evaluates:

assistant identity

operation

authorized purpose

recipient

content/output scope

resource

runtime state

policy/security epoch

revocation state

↓

protected validation succeeds

↓

LAVR / protected validation commitment

↓

bounded non-bearer execution authority is established

↓

Mail prepares the actual message

↓

Finality Sink reconstructs or verifies the load-bearing Candidate Act attributes

↓

compares the actual proposed effect with protected authorization state

↓

if correspondence is established:

SEND

If instead:

• Alice is changed to another recipient;

• an additional hidden recipient is added;

• the itinerary is replaced with another document;

• material content changes;

• authorization is revoked;

• the applicable security epoch changes;

• the authority is replayed;

• another application attempts to use the authority;

• another destination is substituted; or

• a bypass path attempts to effectuate the operation without valid finality authorization,

the Finality Sink can deny the effect on a fail-closed basis.

Why This Matters for AI Interoperability

This distinction becomes particularly important when an operating system is expected to provide multiple competing AI assistants with meaningful access to device capabilities.

One security response is to restrict third-party assistants from accessing powerful system functions.

Another possible architecture is to make the relevant interoperability interfaces broadly available while separating:

access

from

final execution authority.

Under such a model, multiple assistants may use the same request and mediation mechanisms while no assistant—including a platform's own assistant—needs to receive unrestricted authority merely because it can invoke the interface.

The architecture can therefore be expressed as three distinct layers:

Request Layer

Interoperability

Multiple AI systems may request standardized functions.

Authorization Layer

Protected, neutral mediation

Identity, purpose, scope, resource, destination, policy state, and other relevant conditions can be evaluated.

Finality Layer

Independent effectuation enforcement

The actual Candidate Act is verified against protected authorization state before the protected external consequence is released.

The resulting principle is:

Open the interface without automatically opening the execution boundary.

Summary Comparison

Concise Architectural Distinction

Sandboxing controls access.

App Intents control interoperability.

OS brokers control mediation.

Confidential computing protects computation.

OAuth controls delegated API authorization.

Human confirmation captures user approval.

IAM evaluates policy.

SIEM detects and records activity.

Execution Finality controls whether the specific instantiated Candidate Act is permitted to become externally effective.

The defining architectural proposition is therefore:

A system may permit access, authenticate the actor, authorize the API, satisfy policy, securely compute the result, and obtain human approval—while still withholding final effectuation authority until the actual Candidate Act is independently verified at the protected finality boundary.

Notes