Bounded Autonomy for Enterprise AI: Typed Action Contracts and Consumer-Side Execution

1. Problem Statement

Large Language Models (LLMs) are increasingly used as natural language interfaces for enterprise software. However, deploying them as direct system operators is unsafe due to inherent model unreliability (hallucinations, entity confusion, permission overgeneralization).

• The Core Issue: Current approaches treat AI safety as a model-quality problem (better prompting, stronger models) or rely on post-hoc monitoring. This leaves the model too close to raw execution, allowing errors to propagate into unauthorized actions, data corruption, cross-tenant leakage, and irreversible business changes.
• The Gap: Existing guardrails focus on content safety (preventing toxic text) or tool access policies (which tools can be called), but they fail to govern how enterprise side effects are executed once a tool call is made. There is a lack of architectural mechanisms to constrain execution authority, validate payloads before mutation, and enforce multi-tenant context boundaries at the point of action.

2. Methodology: Bounded Autonomy Architecture

The authors propose Bounded Autonomy, a design principle where LLMs act as interpreters and planners, but all executable behavior is mediated by a strict execution architecture. The system is composed of two distinct actors:

A. The Bounded Autonomy Layer (BAL)

BAL is a portable mediation layer that sits between the LLM and the enterprise application. It does not execute business logic but enforces safety constraints:

1. Typed Action Contracts: Enterprise capabilities are not exposed as raw APIs but as structured contracts defining input schemas, permission predicates, validation logic, and execution semantics.
2. Permission-Aware Capability Exposure: BAL computes a "granted actions manifest" at runtime. The LLM only sees actions the specific user is authorized to perform, preventing the model from even considering unauthorized workflows.
3. Pre-Side-Effect Validation: Before any mutation occurs, BAL validates the model's proposed arguments against domain schemas. It enforces required fields and structural validity.
4. Ambiguity Handling: If an entity (e.g., a client named "John") is ambiguous, BAL forces a clarification state rather than guessing, returning structured candidate lists to the user.
5. Confirmation Gates: High-consequence or multi-step workflows are held in a "pending" state requiring explicit human approval before dispatch.
6. Manifest Governance: The LLM reasons over an explicit, versioned, and published manifest of capabilities, preventing it from invoking stale or unregistered actions.

B. The Consumer Application

The enterprise application retains full authority over business logic, data access, and side effects.

• Consumer-Side Execution: BAL routes approved actions through the consumer's own services and API layers. It never bypasses the application's backend.
• Defense in Depth: The consumer application enforces its own authorization, workspace scoping, and domain validation. This provides a secondary safety layer that catches failures BAL might miss.

3. Key Contributions

1. Architectural Paradigm Shift: The paper argues that enterprise AI safety is primarily an execution architecture problem, not a model-quality problem. It defines "Bounded Autonomy" as the operating regime where models propose, but the system executes.
2. The BAL Framework: A portable implementation that enforces typed contracts, dynamic permission filtering, and structured validation before side effects.
3. Consumer-Side Execution Boundary: A design ensuring AI-mediated mutations always traverse the enterprise application's existing safety controls (routes, services, persistence), preserving the "source of truth" for business logic.
4. Empirical Evaluation: A rigorous evaluation in a deployed multi-tenant CRM environment comparing three conditions:
   • Manual Baseline: Human operation.
   • Unconstrained AI: The same system with all BAL safety layers disabled (feature flags).
   • Bounded Autonomy: The full production system.

4. Results

The evaluation involved 25 scenario trials across seven failure families (e.g., unauthorized actions, ambiguous entities, cross-workspace requests).

Key Findings:

• Zero Unsafe Executions: The Bounded Autonomy system intercepted 100% of targeted safety violations (unauthorized actions, malformed payloads, cross-workspace leaks) before they reached the enterprise state.
• The "Wrong-Entity" Failure Class: In the Unconstrained condition, the model confidently selected the wrong entity (e.g., updating the wrong "John") and reported success. This failure class was structurally blind to the consumer application's backend checks (because the user had permission and the payload was valid). Only BAL's disambiguation and confirmation mechanisms intercepted this.
• Utility Improvement: Counter-intuitively, removing safety layers reduced task completion (from 23/25 to 17/25). Without structured validation feedback, the model received generic errors and failed to self-correct, leading to hallucinated success or infinite retry loops. Bounded Autonomy provided structured feedback that guided the model to correct outcomes faster.
• Defense in Depth: When BAL layers were bypassed, the consumer application's backend caught many errors, but not all. This confirms that BAL provides a necessary, portable safety layer that complements, rather than replaces, application-level security.

5. Significance

• Practical Deployment: The architecture is not theoretical; it was implemented and tested in a live multi-tenant enterprise application, proving that safety constraints can be integrated without sacrificing the efficiency gains of AI (13.5x speedup).
• Reframing Safety: The results challenge the assumption that safety and utility are trade-offs. The study demonstrates that architectural constraints can improve utility by providing the structured feedback loops necessary for LLMs to recover from errors.
• Model Agnosticism: The safety guarantees are structural (enforced by code), not statistical (dependent on model intelligence). The system worked equally well with different models (GPT-4o-mini vs. o3-mini), proving that safety is a property of the execution environment, not the model itself.
• Industry Impact: This work provides a concrete blueprint for "Bounded Autonomy," aligning with emerging industry standards (e.g., OpenAI's Agentic Governance, MongoDB's agent patterns) by formalizing how to safely expose enterprise operations to AI agents without risking organizational damage.

In conclusion, the paper establishes that for enterprise AI to be operationally useful, it must move from "unrestricted agent autonomy" to "bounded autonomy," where the enterprise application retains control over execution boundaries, and the AI operates within a governed, typed, and validated contract.