From Access Grants to Executable Authority: Closing the Transaction-Boundary Gap in Agentic Enterprises

Executive Summary

Artificial intelligence (AI) is evolving beyond answering questions and generating content. AI agents are increasingly designed to interact with business applications, update records, manage workflows, and execute tasks across multiple systems. This evolution raises a critical question for enterprises: How can a business ensure an AI agent is authorized to perform a specific action, acts only within its permissions, and leaves reliable evidence of its activities?

Simply granting an AI agent access to a system does not automatically authorize every potential action. For example, an agent might have permission to access a customer database but not to modify every customer record. It might be allowed to prepare a payment but not to approve or release it. Approval for one action might be granted, only for the request to change before execution.

Further problems can arise if a system fails mid-task, a request is repeated, or records are insufficient to confirm an action's success. These challenges intensify when a single workflow spans several business applications, each with unique permissions, rules, and technical limitations.

This article identifies the gap between general system access and properly authorized business actions as the "Transaction-Boundary Gap." To help address this, it introduces two proposed architectural concepts:

• **Transaction-Bound Execution Contract (TBEC):** A proposed method to link a specific action to the necessary permission, approval, conditions, and evidence.
• **Transaction-Boundary Assurance Model (TBAM):** A proposed framework for evaluating an enterprise's ability to demonstrate that its AI agents operate within their authority and that their actions can be retrospectively verified.

These concepts are proposals for architectural discussion, not established industry standards or independently validated security frameworks.

The central argument is straightforward: Enterprises must move beyond merely asking if an AI agent has access. They must also confirm that each significant action is properly authorized, securely executed, and supported by reliable evidence. This is a crucial design consideration for organizations aiming to deploy AI agents while upholding security, accountability, and human control.

1. Why System Access Is Not Enough

Consider an employee authorized to update customer information. While appropriate for routine work, this permission does not necessarily extend to changing every field, modifying every customer account, or performing every action without additional approval.

The same principle applies to AI agents. An AI agent might possess valid credentials and permission to use a business application, yet a particular action could still be inappropriate for several reasons:

• The action exceeds the agent's assigned responsibilities.
• The target record differs from the one covered by the original request.
• A required approval has not been obtained.
• The approved information has changed.
• The agent's permission has expired or been withdrawn.
• A previous attempt may have already completed the action.
• The business cannot reliably determine what happened after a system failure.

The core issue is not necessarily the agent's lack of access. Rather, general access and permission to perform a specific business action are distinct concepts.

A simple example

Imagine a company uses an AI agent to manage supplier records, authorizing it to update certain supplier information. A manager approves a change to one supplier's bank details. However, before the change is submitted, the information in the request is modified.

Should the agent proceed using the original approval? Not automatically. The system must determine if the approval still applies to the exact change being requested.

Now, consider if the update is submitted, but the application provides no response, leaving the agent uncertain whether the change succeeded. In some systems, resubmitting the request might be harmless. In others, repeating the operation could create further problems.

Therefore, the enterprise needs more than just permission to use the application. It requires a reliable way to connect the original request, the approval, the actual operation, and the final result. This is the central problem this article examines.

2. What Is the Transaction-Boundary Gap?

The Transaction-Boundary Gap is a proposed term for the disparity between possessing permission to access a system and being able to demonstrate that a specific business action was properly authorized and correctly executed.

In this context, a transaction signifies a particular business operation, such as altering a customer record, issuing a payment instruction, or updating a production system.

This gap can emerge when different parts of a workflow operate independently. For example, one system verifies the agent's identity, another checks its permissions, a third collects human approval, a fourth executes the operation, and a fifth records the results. Each system may function as designed, yet the enterprise might struggle to prove that the final action aligned with the original authorization. The challenge lies in maintaining the connection between these disparate parts.

2.1 The difference between general permission and specific authority

General permission might be stated as: "This AI agent may update supplier records within an approved scope."

Permission tied to a specific transaction would be more precise: "This AI agent may update these approved fields for this specific supplier, using the authorized information, within the permitted time and subject to the required approval."

The latter approach clarifies the limits of the agent's authority and provides the enterprise a stronger basis for verifying the operation's legitimacy. The objective is not to eliminate general permissions, which remain necessary, but to link them to the exact action being performed.

2.2 Why timing matters

A permission or approval, valid at the time a decision is made, may no longer be valid when the action is performed. For example:

• A manager withdraws an approval.
• The agent's delegation expires.
• A supplier record changes.
• The requested amount is modified.
• A security policy changes before execution.

If the system checks conditions only at the beginning of a workflow, it may miss important changes that occur later. This relates to a known software security vulnerability called a time-of-check/time-of-use (TOCTOU) vulnerability. Simply put, TOCTOU occurs when a system checks if an action is allowed, but the relevant conditions change before the system acts on that decision. A robust design re-checks important conditions immediately before the action is executed. The specific controls required depend on the operation's risk and the capabilities of the system performing it.

3. What Existing Standards and Technologies Contribute

Enterprises do not need to build every security control from scratch. Existing standards and technologies provide essential building blocks for identity, authorization, secure communication, and access management. However, these building blocks should not be mistaken for a complete solution to every problem associated with AI agent execution.

OAuth 2.0 Token Exchange

The Internet Engineering Task Force (IETF) published RFC 8693, defining a standard for exchanging security tokens. Practically, this helps one service obtain a token representing an appropriate identity or delegated authority when interacting with another service. This is useful when an AI-enabled application needs to access a downstream system under defined security conditions. However, token exchange alone does not guarantee that a particular business transaction will be executed only once, remain consistent with human approval, or be fully recoverable after a failure.

Reference: https://www.rfc-editor.org/rfc/rfc8693

Model Context Protocol

The Model Context Protocol (MCP) offers a standard approach for connecting AI applications to external tools and services. Its authorization mechanisms help control access to protected MCP servers, which is crucial for securing AI tool interactions. However, permission to access a tool does not automatically confirm that every operation performed through that tool is appropriate, approved, or safely completed. These questions may require additional controls at the application, workflow, and business transaction levels.

Reference: https://modelcontextprotocol.io/

NIST research on agent identity and authorization

The U.S. National Institute of Standards and Technology (NIST), through its National Cybersecurity Center of Excellence, has been exploring approaches to software and AI agent identity and authorization. This work is relevant for organizations aiming to apply established security practices to systems that can act on behalf of individuals or organizations.

Reference: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization

OWASP agentic AI security guidance

OWASP publishes security guidance for AI applications, including risks associated with agentic systems. Such resources can help organizations identify risks involving excessive permissions, unsafe tool use, and other weaknesses in AI-enabled workflows.

Reference: https://genai.owasp.org/

What these technologies mean for enterprises

Collectively, established identity, authorization, and security practices provide an important foundation. The remaining architectural challenge is to link these controls to the specific business operation and its final outcome. An enterprise must be able to answer four practical questions:

• **Permission:** Was the agent allowed to perform this action?
• **Consistency:** Did the action match the approved request?
• **Execution:** What actually happened when the action was attempted?
• **Evidence:** Can the enterprise independently verify the result?

These questions form the basis for the proposed approach that follows.

4. A Proposed Solution: The Transaction-Bound Execution Contract

This article proposes a concept called the "Transaction-Bound Execution Contract" (TBEC). The idea is to create a clear relationship between a specific business action and the conditions that must be satisfied before that action can proceed. Instead of relying solely on a broad statement that an AI agent has system access, the design would specify what the agent is allowed to do in a particular situation.

A transaction-bound contract could include the following information:

• **Responsible authority:** The person or organization from which the permission originates.
• **AI agent identity:** Which agent is requesting the action.
• **Delegated permission:** What the agent is allowed to do and the limits of that permission.
• **Requested operation:** The exact type of action being requested.
• **Target resource:** The account, record, service, or other resource affected.
• **Approved information:** The important values or parameters that the action is allowed to use.
• **Policy decision:** Whether the request satisfies the applicable business and security rules.
• **Human approval:** Whether a required person has approved the relevant action.
• **Validity conditions:** When the permission applies and which conditions must remain valid.
• **Operation identifier:** A reference used to track the same logical operation across attempts and systems.
• **Duplicate-handling rules:** How the system detects or manages repeated requests.
• **Evidence requirements:** Which records are needed to establish what happened.

This table describes a proposed design approach, not a mandatory industry format. Different enterprises may implement these elements using different technologies. The important point is that the system should be able to connect the permission, the approved action, the execution attempt, and the resulting state.

4.1 Make the permitted action specific

An AI agent might be allowed to update a customer record but not permitted to change every field within it. The enterprise could restrict the agent to specific fields and define the values it may submit. For higher-risk actions, additional conditions could apply. For example, a financial instruction might require a verified destination, a defined amount, and approval from an authorized person. The system should evaluate the requested operation against these conditions before allowing it to proceed.

This leads to a fundamental principle: An AI agent's technical ability to perform an action must not be treated as proof that it has permission to perform that action. A tool may technically support an operation that the agent is not authorized to carry out. The authorization system must enforce this distinction.

4.2 Make approval apply to the correct request

Human approval is valuable only when the system can confirm what was approved. If a manager approves one set of transaction details, the system should not automatically treat that approval as valid for a materially different request.

One possible approach is to create a structured representation of the approved transaction and protect its integrity using appropriate cryptographic mechanisms. The system can then check whether the transaction presented for execution matches the approved representation. This can help detect unauthorized changes. However, cryptographic protection alone does not prove that the approver was authorized or that the original information was correct; those questions require separate controls. The enterprise must also define which changes are significant enough to necessitate new approval.

4.3 Check permission immediately before execution

Before performing a consequential operation, the execution system should verify the relevant conditions. These checks may include:

• Is the agent's identity valid?
• Is its delegated permission still active?
• Does the requested operation match the approved scope?
• Is the target resource correct?
• Do the important parameters match the approved request?
• Is the required human approval still valid?
• Have any relevant conditions changed?
• Has the same logical operation already been completed?
• Can the target system safely perform the requested operation?

If a required condition cannot be confirmed, the system should follow a defined response. Depending on the situation, that response might be to reject the operation, place it on hold, request additional approval, or escalate it to a human. A required security check should not be silently bypassed merely because the workflow has already started.

4.4 Recognize the limits of the execution system

A central authorization service cannot guarantee every aspect of a downstream operation. Suppose a gateway checks the transaction and then sends an update request to another application. The target record might change between the check and the update. Where available, target-side safeguards—such as version checks, conditional updates, or idempotency mechanisms—can help reduce this risk.

Idempotency means that repeating the same logical request does not produce an additional unintended effect, provided the receiving system implements the necessary guarantees. Not every application supports these mechanisms. If the target system cannot reliably establish whether an operation succeeded, the enterprise may need to reconcile the state, hold further actions, or request human intervention. A control plane can coordinate and govern actions, but it cannot guarantee behavior that the underlying systems do not support.

5. A Practical Architecture for Transaction-Bound Execution

The proposed architecture connects the main stages of an AI-driven business operation. The process can be understood as follows:

Human or Organizational Authority ↓ Identity and Delegation ↓ Business Context and Policy Checks ↓ Transaction-Bound Execution Contract ↓ Execution-Time Enforcement ↓ Business Application ↓ Outcome Verification and Evidence

Monitoring, revocation, and human intervention apply across the entire process. Each stage has a distinct responsibility.

Stage 1: Establish identity

The enterprise identifies the person or organization responsible for the request and the AI agent that will perform the work. It should distinguish the original authority from the agent and any intermediate services. This distinction is important because identifying a service that made an API call is not always sufficient to establish who authorized the underlying business action.

Stage 2: Define the limits of permission

The system determines what the agent is allowed to do. It evaluates the requested action against applicable rules, business context, delegated authority, and risk requirements. For example, an agent may be permitted to prepare a transaction but not finalize it without human approval.

Stage 3: Connect permission to the specific action

The proposed TBEC records the relationship between the requested action and its relevant conditions. It can provide a consistent reference for checking the operation throughout the workflow. The enterprise must also ensure that the authority to create or approve the contract is itself properly controlled.

Stage 4: Enforce the conditions

Before execution, the system checks whether the operation still satisfies the required conditions. These checks should occur as close to the consequential action as practical. If a workflow involves multiple systems, the enterprise must define what happens when a later step becomes invalid after an earlier step has already completed.

Stage 5: Perform the operation

The target application carries out the requested action under its own security and transaction rules. Where possible, the operation should include identifiers or conditions that help the target system recognize the logical transaction and manage repeated requests. The target application remains an important security boundary.

Stage 6: Verify the outcome

The system records what happened and distinguishes between a request being submitted and the intended change actually being completed. For example, an operation may be:

• Authorized but not yet submitted.
• Submitted but not confirmed.
• Completed successfully.
• Partially completed.
• Rejected.
• Left in an uncertain state that requires investigation.

These outcomes must not be treated as equivalent. The evidence should enable an authorized reviewer to reconstruct the important events without depending exclusively on the AI agent's own explanation.

6. A Proposed Framework for Assessing Assurance

This article also proposes the "Transaction-Boundary Assurance Model" (TBAM). TBAM is intended to help enterprises evaluate whether their AI agent workflows adequately connect permission, execution, and evidence. It is a conceptual framework for further research and testing—not an established industry standard or a validated certification scheme.

The proposed model contains eight assessment areas.

1. Action specificity

**Question:** Does the system clearly define what the agent is allowed to do?

The assessment should examine whether the permission identifies the relevant operation, resource, and important parameters. Broad access may be insufficient for high-impact actions.

2. Authorization integrity

**Question:** Can the enterprise establish that the executed operation matches the authorized request?

Relevant controls may include protected transaction records, stable identifiers, approval references, and validation of important parameters.

3. Duplicate protection

**Question:** Can the system detect or prevent unintended repeated operations?

The assessment should examine how the system handles retries, repeated requests, and uncertain outcomes. Assigning an identifier to a request does not, by itself, guarantee that an operation will occur only once.

4. Time validity

**Question:** Does the system verify that permission and other important conditions remain valid when the action is performed?

Relevant factors include expired delegation, withdrawn approval, changes to the target resource, and updated policies.

5. Approval integrity

**Question:** Can the system demonstrate that the required person approved the correct action?

The existence of an approval record is not enough if that approval does not apply to the transaction being executed.

6. Enforcement

**Question:** Are the required controls enforced where they can actually prevent unauthorized actions?

The assessment should examine whether an agent or intermediary can bypass the expected enforcement mechanism.

7. Failure handling

**Question:** Can the enterprise manage failures, partial completion, and uncertain outcomes safely?

The assessment should consider recovery procedures, reconciliation, escalation, and restrictions on further actions while the outcome remains uncertain.

8. Evidence quality

**Question:** Can an independent reviewer establish what was authorized, what was executed, and what happened afterward?

The evidence should connect identity, permission, approval, execution attempts, and observed results. It should also capture relevant failures and interventions.

How enterprises could use TBAM

An organization could assess each area using four descriptive levels:

• **Not established:** The required control has not been demonstrated.
• **Partially established:** Some controls exist, but important limitations remain.
• **Enforced:** The relevant controls are implemented at the necessary points.
• **Verified:** Testing provides evidence that the controls work under defined conditions.

These levels are proposed for this article and would require further definition before being used as a formal assessment method. A numerical score should not be introduced without a documented methodology, clear assessment criteria, and appropriate evidence. Different business operations may also require different levels of assurance. A routine, reversible change may not need the same controls as a high-impact financial transaction.

7. What Can Go Wrong—and How Enterprises Can Respond

A reliable design must consider what happens when the workflow does not proceed as expected.

When permission changes

An agent begins a task with valid permission, but that permission is withdrawn before a later action.

**Possible response:** Recheck the relevant authority before consequential steps and define how in-progress operations are handled.

When an approved request changes

A person approves one action, but the requested parameters are modified before execution.

**Possible response:** Check whether the approval still applies. Require renewed approval when a material change invalidates the original decision.

When a request is repeated

A timeout leaves the system uncertain about whether an operation succeeded.

**Possible response:** Check the transaction's status and use appropriate duplicate-handling controls rather than blindly repeating the request.

When a workflow stops halfway

One application completes an update while another application fails.

**Possible response:** Identify the resulting state, prevent further unsafe actions, and follow a defined recovery or compensation process. A distributed workflow does not automatically behave like one atomic transaction. Each participating system may have different guarantees.

When an agent is manipulated

Untrusted content or malicious instructions cause an agent to attempt an action beyond its assigned authority.

**Possible response:** Enforce authorization outside the AI model's reasoning process. The model may propose an action, but a separate control must determine whether the action is allowed.

When the evidence is incomplete

A system reports success, but the available records cannot establish which permission authorized the action or whether the intended change occurred.

**Possible response:** Connect the execution record to the authorization decision and verify the outcome against an appropriate source of truth.

When a security check becomes unavailable

A required authorization service cannot respond, and the workflow is unable to confirm whether execution is permitted.

**Possible response:** Apply an explicit failure policy. For consequential operations, the system should not silently assume that a missing security decision means permission has been granted.

The appropriate response depends on the operation's risk and the enterprise's requirements.

8. Why Recovery Matters as Much as Prevention

Security discussions often focus on preventing unauthorized actions. Prevention is essential, but it is not enough. Enterprise systems must also handle operations that fail, produce uncertain results, or complete only partially.

Consider a workflow that updates two business applications. If the first update succeeds but the second fails, the enterprise needs to decide what to do with the partially completed workflow. Depending on the business process, it might retry the second step, reverse an earlier change through a separately authorized action, reconcile the records, or ask a human to resolve the inconsistency. There is no single recovery method that works for every operation. The architecture must define the available options and their limitations.

8.1 Revoking permission does not reverse completed work

If an agent's permission is withdrawn, the system may be able to prevent future actions. However, the revocation does not automatically reverse an operation that has already completed. Enterprises should therefore distinguish between:

• Preventing new actions.
• Stopping in-progress actions where technically possible.
• Investigating uncertain outcomes.
• Correcting completed actions where appropriate.
• Preserving evidence of the original action and the corrective response.

A corrective action should itself be properly authorized. The objective is not to erase the past but to restore the intended business state while maintaining an accurate record of what happened.

8.2 Records are not the same as proof

A system may keep detailed logs, but the existence of logs does not automatically prove that every action was correct. A trustworthy evidence process depends on several factors:

• The reliability of the source records.
• The integrity of the collection process.
• The completeness of the relevant events.
• The ability to connect events across systems.
• The ability to verify the actual outcome.

Even tamper-evident records cannot independently prove that the original approval was legitimate or that the target system reported accurate information. Evidence must therefore be evaluated according to what it can actually establish.

9. The Role of Human Control

AI agents may be able to carry out work with limited human involvement, but enterprise autonomy should not mean unrestricted authority. Human oversight should be supported by practical controls. Depending on the operation and the system's capabilities, authorized people may need to:

• Approve high-impact actions.
• Place a pending operation on hold.
• Withdraw an agent's delegated permission.
• Require a new approval.
• Suspend a workflow.
• Initiate a recovery procedure.
• Review the evidence of a completed action.

These controls must have clearly defined effects. For example, stopping a workflow may prevent later steps without canceling an operation already accepted by an external system. An enterprise should not promise that a human override can instantly reverse every action unless the underlying systems genuinely support that behavior.

The governing principle is: AI agents should act within clearly defined authority, while humans retain meaningful control over decisions that require human judgment or intervention.

10. What This Means for an Autonomous Enterprise Control Plane

An autonomous enterprise uses AI agents and connected software to perform work across different business systems. As these environments become more capable, enterprises need a coherent way to coordinate identity, permissions, policy, execution, recovery, and evidence. This is where an enterprise control plane architecture becomes relevant.

A control plane can help coordinate how work is authorized and performed across multiple systems without replacing every application or infrastructure component. Its responsibilities may include:

• **Understanding context:** Establishing the business situation and relevant information.
• **Applying governance:** Evaluating organizational policies and restrictions.
• **Managing authority:** Determining which actions an agent is allowed to perform.
• **Coordinating execution:** Routing approved actions through appropriate controls.
• **Handling failures:** Supporting holds, escalation, reconciliation, and recovery.
• **Maintaining evidence:** Connecting decisions, execution attempts, and observed outcomes.
• **Supporting human intervention:** Providing mechanisms for authorized people to stop or redirect work.

These functions may be distributed across several technologies. Identity providers, policy engines, workflow platforms, target applications, and audit systems can each contribute to the overall architecture. The important requirement is that their responsibilities work together coherently.

10.1 Relevance to AEOS QUANTUM™

The principles discussed in this article are relevant to the architectural direction of AEOS QUANTUM™, which is intended to connect, orchestrate, govern, and activate enterprise systems rather than replace the entire enterprise technology stack. Within that direction, transaction-bound assurance could help guide how delegated authority, policy decisions, execution pathways, and evidence are coordinated across connected applications.

However, this article does not establish that AEOS QUANTUM currently implements the proposed TBEC or TBAM concepts. It also does not claim that AEOS QUANTUM has independently validated transaction-bound execution guarantees. Those claims would require documented implementation, appropriate technical testing, and evidence supporting the specific capabilities being described. A proposed architecture is a direction for development—not proof that the corresponding capabilities are already available. Maintaining this distinction is important for technical credibility and responsible product communication.

11. How the Proposed Approach Could Be Tested

The next step for TBEC and TBAM is practical evaluation. The concepts should be tested against realistic business workflows to determine whether they help enterprises identify and address authorization gaps.

Test 1: A request changes after approval

An AI agent receives approval for an operation. An important parameter changes before execution.

**Question:** Does the system detect the change and require a new approval when necessary?

Test 2: A request times out

The target application may have completed an operation, but the orchestration system receives no response.

**Question:** Can the enterprise establish the operation's status without creating an unintended duplicate?

Test 3: Permission is withdrawn

An agent's delegated authority is revoked while a workflow is still in progress.

**Question:** Does the system prevent unauthorized later actions and handle previously completed steps appropriately?

Test 4: Only part of a workflow succeeds

One application completes its update, while another fails.

**Question:** Can the system identify the inconsistency and follow an appropriate recovery process?

Test 5: Important evidence is missing

An operation appears to have succeeded, but one or more authorization or execution records are unavailable.

**Question:** Does the system identify the evidence gap instead of treating the operation as fully verified?

Test 6: An agent attempts to bypass a control

An agent attempts to reach a business application through a route that avoids the expected enforcement mechanism.

**Question:** Can the enterprise prevent or detect the bypass and enforce equivalent protections where necessary?

What a proper evaluation should include

For every test, researchers should document:

• The systems and configurations being tested.
• The expected security and operational behavior.
• The actual results.
• The evidence supporting those results.
• The limitations and assumptions.
• Any remaining risks.
• The conditions under which the findings can reasonably be applied to other environments.

This process would help establish whether TBEC and TBAM provide practical value beyond their conceptual description. Until that evaluation is performed, the two concepts should remain proposals rather than being presented as proven solutions.

12. Conclusion: From System Access to Accountable AI Action

AI agents are becoming increasingly capable of carrying out work across enterprise systems. This creates an important responsibility: Organizations must ensure that greater capability does not automatically translate into greater authority.

Authentication helps establish identity. Access controls define permitted operations. Delegation determines which authority an agent may exercise. Policy evaluation helps determine whether an action is allowed.

However, consequential actions introduce additional questions: Does the operation match the approved request? Is the required permission still valid? Can unintended duplicate execution be avoided? What happens if the workflow fails? Can the enterprise establish what actually occurred?

These questions demand more than a capable AI model or a valid access token. They require an architecture that connects authorization, execution, recovery, and evidence.

The proposed Transaction-Bound Execution Contract offers one way to describe how permission could be connected to a specific business action. The proposed Transaction-Boundary Assurance Model offers a structure for evaluating whether that connection is sufficiently reliable. Both concepts require further development and practical testing. Neither is presented as an established industry standard or a guarantee of secure execution.

The broader lesson is clear: Having access to a system is not the same as having authority to perform every action within it. And receiving permission to act is not the same as proving that an action was executed correctly. For enterprises adopting AI agents, the goal should not simply be to automate more work. It should be to enable automation that respects delegated authority, follows enforceable rules, handles failures responsibly, and produces evidence that people can independently review. That is how organizations can move from granting AI agents access to building more accountable systems for AI-driven business execution.

References and Further Reading

The following resources provide background for the article's discussion of identity, authorization, and agentic AI security.

1. **IETF — RFC 8693: OAuth 2.0 Token Exchange** A technical standard for exchanging security tokens, including delegation-related use cases. https://www.rfc-editor.org/rfc/rfc8693 2. **Model Context Protocol (MCP)** Documentation for the protocol used to connect AI applications with tools and external systems, including authorization-related guidance. https://modelcontextprotocol.io/ 3. **NIST National Cybersecurity Center of Excellence — Software and AI Agent Identity and Authorization** Research on identity and authorization approaches for software and AI agents. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization 4. **OWASP GenAI Security Project** Security resources addressing risks in generative AI and agentic applications. https://genai.owasp.org/

Research Note

The Transaction-Bound Execution Contract (TBEC) and Transaction-Boundary Assurance Model (TBAM) are proposed concepts introduced in this article. They are not represented as standards issued or endorsed by IETF, NIST, OWASP, or the Model Context Protocol project. The architecture is a research proposal. Actual security and reliability depend on implementation, the guarantees provided by participating systems, and appropriate testing.