Trust-Aware Orchestration Architecture for LLM-Assisted Workflows in Multi-Tenant Enterprise Systems

You’re listening to “Trust-Aware Orchestration Architecture for LLM-Assisted Workflows in Multi-Tenant Enterprise Systems,” by N. Leburu. Published in 2026.

Abstract.

Large language models (LLMs) now call tools and APIs in enterprise systems, creating concrete risks: hallucinated parameters, cross-tenant data leakage, and prompt injection. This paper presents an orchestration architecture for multi-tenant deployments where the LLM proposes actions and a deterministic control plane validates and executes them, organized as three hard enforcement gates (authentication and tenant resolution, role-based tool authorization, and schema validation), four advisory filters (input sanitization, retrieval scoping, execution monitoring, output compliance), and append-only audit logging.

The hard gates provide three structural guarantees (tenant isolation, tool-allowlist enforcement, schema conformance) specified as deterministic predicates and verified at the logical control-plane level; they do not defend against within-scope intent manipulation, in which an authorized role invokes an authorized tool with schema-valid parameters for a malicious purpose. A 20-prompt adaptive case study shows within-scope attacks succeed on every one of five LLMs tested, at point-estimate rates of 30%–70%, including the three frontier Claude models (Haiku 4.5, Sonnet 4, Opus 4.6). The structural guarantees hold uniformly across 14,885 evaluations: 1,497 custom prompts plus adversarial prompts from two established benchmarks (683 TensorTrust and 777 AgentDojo across three domains and three attack strategies) and a 20-prompt adaptive case study.

Targeted attack-success rate on AgentDojo is ≤ 1.9% across all five models, comparable to published defended baselines. Deterministic syntax recovery reduces the 3B model’s false rejection rate from 52% to 15.2% at zero latency cost; frontier models achieve 0%. Input sanitization flagged injection patterns in only 10.2% of injection prompts without solo-rejecting any, confirming pattern-based detection is insufficient. Within-scope intent manipulation remains an open problem the hard gates do not address. The architecture targets enterprise systems requiring explainability, safety, and regulatory compliance.

Introduction.

Large language models are no longer just chat interfaces. They now call tools, query databases, and trigger API actions inside enterprise software. Advances in tool invocation,, retrieval-augmented generation, and agent-based reasoning have made this practical. An LLM can look up a customer record, create an invoice, or initiate a fund transfer, all from a natural language prompt.

The associate editor coordinating the review of this manuscript and approving it for publication was Jonathan Rodriguez.

The problem is that LLMs are probabilistic. They generate outputs based on statistical patterns, not deterministic rules. A model can hallucinate wrong parameters for an API call (e.g., transferring $10,000 instead of $100), or generate a call to a tool that does not exist. When the model interacts with real tools and databases, these errors have real consequences. In multi-tenant platforms (where multiple organizations share a single orchestration layer), one cross-tenant data leak or one unauthorized tool call creates compliance exposure. Multi-tenant data centers already struggle with traffic separation, and shared data services add elasticity and cost-sharing challenges.

Adding an LLM that can reach across tenant boundaries makes things worse.

Existing defenses focus on prompt engineering, output filtering, or model alignment. These help, but they are not enough for regulated enterprises that need hard guar-antees on correctness, access control, and auditability. In most deployed systems today, the LLM is the implicit authority: its output flows directly to tool execution with minimal validation. This makes it difficult to enforce deterministic behavior, trace decision paths, or prevent unsafe tool calls.

The core argument of this paper is straightforward: you cannot make an LLM trustworthy by making it smarter. Trust must be established at the architecture level. The term ‘‘trust-aware’’ here means three things: trust is quantified via per-layer scoring, trust boundaries are enforced through deterministic gates, and trust provenance is maintained through immutable audit trails. This is different from ‘‘trustworthy AI’’ frameworks, that focus on model-level properties like fairness and robustness. The focus here is on architectural mechanisms that make the system trustworthy regardless of how the model behaves. The LLM should be an advisor. It proposes; the system decides.

This paper presents such an architecture for multi-tenant enterprise systems. It combines deterministic orchestration, tenant-isolated retrieval, schema-validated tool execution, role-based policy enforcement, and a guardrail pipeline organized as three hard gates (authentication and tenant reso-lution, policy and tool authorization, and schema validation), together with four advisory filters (input sanitization, retrieval scoping, execution monitoring, and output compliance). The hard gates carry the load-bearing security guarantees and produce binary pass/fail decisions; the advisory filters contribute heuristic signals to a per-request trust score and address threats the hard gates do not target directly. The core enforcement mechanisms are specified as deterministic predicates and validated through simulation and empirical testing.

To make this concrete early: Section IX walks through two end-to-end scenarios (a valid tool invocation and a prompt injection attempt), showing how each pipeline layer processes the request.

The individual enforcement mechanisms (role-based access control [RBAC], schema validation, tenant scoping, audit logging) are established. What is missing is a mandatory composition that no LLM output can bypass, and data on what actually happens when real models run inside it. The contributions are:

1) An orchestration architecture that composes five.

enforcement mechanisms (tenant-isolated retrieval, schema-validated tool execution, role-based policy, layered guardrails, audit logging) into a single manda-tory pipeline with logically specified trust boundaries. No gate is optional; no LLM output reaches a tool without passing all of them.

2) Logical specifications of the tenant isolation invariant.

and validation gate as deterministic predicates, with correctness arguments showing that cross-tenant access is prevented by construction at the logical control-plane level.

3) Empirical characterization of five LLMs (two open-.

weight at 3B and 13B parameters, three frontier commercial models) under mandatory enforcement across 1,497 custom prompts, 683 TensorTrust and 777 AgentDojo adversarial benchmark prompts span-ning three domains and three attack strategies, and a 20-prompt adaptive case study, for 14,885 evaluations total. Across all evaluations, no tool execution used a tool outside the role’s authorized tool allowlist; this is a by-construction correctness property (the LLM never sees unauthorized tools to call) verified empirically. The interesting findings are within the authorized scope: an adaptive case study of within-scope intent-manipulation attacks (authorized role, authorized tool, schema-valid parameters) succeeded at 30%–70% across the five models, quantifying the intent-vs-structure gap that hard gates cannot close.

False rejection rates range from 0% for frontier models to 15.2% for the smallest (with deterministic syntax recovery), driven by tool-calling fidelity.

4) Control-plane implementation verification through.

simulation under five adversarial scenarios, confirming schema violation catch rates above 0.99, logical tenant isolation (Eq. 2) enforced on every code path under assumptions A1 and A5, and false rejection rates below 0.02.

II. RELATED WORK.

A. AGENTIC LLM SYSTEMS AND TOOL INVOCATION

LLM-based tool use has advanced along three lines. First, models that learn to call APIs during generation: ReAct interleaves reasoning with actions, Toolformer teaches self-directed API calls, and Gorilla reduces API hallu-cination through documentation-grounded training. Second, orchestration frameworks for multi-step planning: Hugging-GPT and ToolLLM coordinate tool calls across planning stages, multi-agent architectures distribute tasks among cooperating models, and AgentBench benchmarks agents across environments. Third, infrastructure-level trust for shared LLM resources: Luo et al. examine orchestra-tion when multiple LLMs share edge infrastructure. Broader surveys, document the field’s growth.

More recently, enterprise-oriented orchestration has emerged: LangGraph introduces stateful agent graphs with checkpointing, Amazon Bedrock Agents provides managed guardrails with knowledge base integration, and Microsoft Semantic Kernel offers plugin-based tool orchestration with role-based filtering. These frameworks move toward production readiness but treat safety mech-anisms as configurable options rather than mandatory enforcement gates.

In all three lines, the LLM retains implicit execution authority. Tool invocation is coupled directly to model output with validation limited to prompt-level constraints. This is fragile in enterprise environments where a wrong tool call carries compliance risk, and most frameworks assume a single-tenant setting.

B. RETRIEVAL-AUGMENTED GENERATION

RAG grounds LLM responses in external documents to reduce hallucination. Recent work improves two aspects: when to retrieve (active retrieval decides dynamically; Self-RAG adds self-reflective critique) and who can access what (Jeong and Lee enforce identity-based filtering so retrieval respects per-user permis-sions). Gao et al. survey these advances.

Retrieval alone does not guarantee safe execution. The model can misinterpret or ignore retrieved content, and most RAG pipelines target informational responses, not executable actions. RAG is a grounding mechanism, not a trust solution.

C. STRUCTURED OUTPUT AND SCHEMA VALIDATION

Constraining LLM outputs to match structured schemas improves downstream integration. LMQL treats prompt-ing as programming with typed constraints. Outlines and grammar-constrained decoding enforce structure during generation. PICARD applies incremental parsing for SQL. Park et al. show that naive grammar-constrained decoding distorts the model’s distribution and propose a corrected algorithm. Synchromesh applies constrained decoding to code generation.

All of these treat schema constraints as generation-time aids, not execution gates. Validation failures are handled reactively. Schema enforcement is rarely integrated with access control, tenant isolation, or audit logging. In enterprise settings, schema validation must be a hard gate: invalid outputs must never reach external tools.

D. LLM GUARDRAILS AND SAFETY

NeMo Guardrails provides programmable rails for LLM behavior. Llama Guard classifies inputs and outputs for safety. Red teaming and adversarial attacks expose vulnerabilities in aligned models. Indirect prompt injection shows that retrieval-integrated applications face additional attack surfaces. The OWASP Top 10 for LLM Applications catalogs the most critical deployment risks. TrustLLM proposes a trustworthiness benchmark.

These efforts are model-centric. They improve the model’s safety but do not specify how safety controls integrate into an execution architecture that enforces trust boundaries across retrieval, reasoning, and action.

E. AI GOVERNANCE AND TRUST FRAMEWORKS

Standards and academic surveys (NIST AI RMF and its generative AI profile, ISO/IEC 42001, the EU AI Act, IEEE 7000, Kaur et al., Li et al. ) specify governance requirements but leave the runtime-enforcement substrate to implementers.

F. MULTI-TENANT SYSTEMS AND ISOLATION

Del Piccolo et al. survey network isolation in multi-tenant data centers, covering VLANs, virtual network over-lays, and SDN approaches. Kumar et al. analyze security challenges in multi-tenant cloud architectures, including co-resident attacks and side-channel leakage. Narasayya and Chaudhuri examine multi-tenant data services from the perspective of elasticity, SLAs, and performance isola-tion. Farhadighalati et al. review access control models. Ali et al. address performance isolation between co-located tenants. When LLM workloads share infrastructure across tenants, context leakage through shared model state or retrieval indexes compounds these existing challenges.

G. POSITIONING

Prior work addresses agentic LLMs, retrieval grounding, structured generation, safety, and governance separately. In each case, the LLM retains implicit execution authority.

Industrial orchestration frameworks cover parts of the problem. LangGraph adds human-in-the-loop interrupts and Pydantic-based schema validation, but these are opt-in; the default gives the LLM control over tool selection, with no built-in tenant isolation or layered guardrails. Semantic Kernel supports JSON schema validation and tag-based multitenancy through Kernel Memory, but does not enforce isolation at every pipeline stage. NeMo Guardrails operates at the prompt/response level; schema validation requires external libraries, and tenant scoping is not built in. Amazon Bedrock Guardrails with AgentCore provides policy-enforced tool allowlisting, IAM-based permissions, schema validators, and signed audit logs, but these are configurable extensions, not mandatory gates, and no formal predicates are provided.

Azure AI Content Safety focuses on content filtering and does not address tool execution governance.

Concurrent academic work covers narrower axes. AgentSpec proposes a customizable runtime enforce-ment DSL for LLM agents; solver-aided policy compliance verification applies SMT encoding to tool-use policies. On injection defense specifically, ClawGuard provides a runtime rule set against indirect prompt injection, and ProbGuard adds probabilistic runtime monitoring. The closest design-space neighbor is CaMeL, which builds a deterministic control plane around an LLM with capability-based information-flow control, separating Privileged and Quarantined LLMs, and reports 77% provably-secure task completion on AgentDojo. CaMeL addresses single-tenant capability flow; this paper addresses multi-tenant RBAC, tenant isolation, and schema-validated execution composed into a mandatory pipeline. He et al. survey LLM-agent security and privacy more broadly.

The OWASP Top 10 for Agentic Applications (2026) provides a threat taxonomy aligned with the threat categories in Section III.

Table 2 summarizes these differences as of early 2026; cloud-provider capabilities evolve rapidly. This paper makes a specific design choice: enforcement is mandatory, not configurable, so no request path can bypass L3 or L5, even through misconfiguration. The individual mechanisms (RBAC, schema validation, tenant scoping, audit logging) are available in existing frameworks. The contribution is composing them into a single mandatory pipeline with logically specified predicates, and testing what happens when five real models run inside it.

What distinguishes this composition is that the LLM cannot invoke tools, access data, or modify state under assumptions A1–A5, so execution authority is separated by construction rather than by opt-in configuration; the five enforcement mechanisms run as a single deterministic pipeline with logically specified predicates; and multi-tenant isolation is enforced at every pipeline stage, not offered as a configurable extension.

Table 1 positions this work alongside concurrent academic systems. AgentSpec provides a DSL for runtime enforcement but treats tool authorization and tenant iso-lation as user-supplied policies rather than built-in gates. ClawGuard and PromptArmor target indirect prompt injection more strongly than this work’s L1 (and could in principle replace L1 in the pipeline; the architecture is agnostic to which injection defense is plugged in). ProbGuard provides probabilistic runtime monitoring complementary to the deterministic gates here. None of these academic systems addresses multi-tenant isolation or composes the full set of enforcement primitives into a single mandatory pipeline; they are best read as components that could be combined, not as alternatives to the present architecture.

Mandatory composition matters in three deployment situations. Regulated multi-tenant SaaS (fintech, ad-platform, B2B SaaS) needs tenant isolation enforced uniformly at each stage rather than configured per integration. Compliance audits need a complete tool-call provenance record for any tenant’s operators, regardless of which tools they used. Model replacement (swapping a frontier model for a cheaper alternative) must not change enforcement behavior, which the empirical results (Section XI) confirm: zero tool executions outside the requesting role’s allowlist across all five models tested.

The proof-of-concept (Section XI) uses banking-flavored tools because the finance domain admits unambiguous correctness criteria (amount ranges, account formats, autho-rization rules) that make schema validation and policy enforcement legible; the pipeline structure transfers without modification to advertising, workspace, and other multi-tenant verticals.

III. THREAT MODEL AND PROBLEM STATEMENT.

The architecture’s guarantees depend on five assumptions. These assumptions scope every correctness claim in the paper; Table 3 maps what happens when each is violated.

A1 (Correct credential binding). The authentication subsystem (L2) correctly resolves tenant identity and user role from presented credentials. Credential forgery, session hijacking, and identity provider compromise are outside scope.

A2 (Schema completeness). Tool schemas specify all required fields, types, and value ranges. Incomplete schemas (e.g., missing range bounds) degrade enforcement proportionally to the omission.

A3 (Policy completeness). Role-based access control policies correctly encode authorized (tenant, role, tool) triples. Missing rules default to deny. Policy misconfiguration (overly permissive rules) weakens enforcement.

A4 (Single-request scope). Each request is evaluated independently. Multi-turn composition attacks, where indi-vidually benign requests combine into an unauthorized sequence, are not detected by the current architecture.

A5 (Logical isolation only). Tenant isolation holds at the logical control-plane level. Physical side channels (GPU memory during batch inference, KV-cache state, shared embedding model activations) require complementary infrastructure mechanisms not specified here.

Five concrete failure modes define what the architecture must prevent. Each arises when LLMs operate as tool-calling agents in multi-tenant systems.

T1: Hallucinated tool parameters. The LLM generates plausible but wrong parameters for an API call: a fabricated customer ID, an out-of-range amount. Without validation, the call corrupts data or triggers unintended operations.

T2: Cross-tenant data leakage. Context from one ten-ant (retrieved passages, conversation history, tool results) contaminates another tenant’s request. This can happen through shared retrieval indexes, model context windows, or insufficiently scoped tool namespaces.

T3: Prompt injection leading to unauthorized tool invocation. An adversary embeds hidden instructions in user input or retrieved content, tricking the LLM into calling tools beyond the user’s authorized scope. The model cannot distinguish instructions from data.

T4: Stale RAG context. Retrieved passages are outdated. The LLM generates responses grounded in stale information, producing incorrect guidance or invalid tool parameters.

T5: Schema bypass. The LLM produces outputs that skip structural constraints: missing required fields, wrong types, values outside permitted ranges. Without hard schema enforcement, malformed outputs reach external systems.

Scope boundaries. These five threats target the orches-tration control plane. The architecture does not defend against:

• Model extraction via API probing.

• Training-data poisoning and adversarial ML attacks (backdoored fine-tuning, universal adversarial suffixes).

• Multi-turn manipulation, where individually benign requests compose into an unauthorized sequence.

• Steganographic exfiltration and denial-of-service through inputs that maximize guardrail cost.

• Deserialization attacks on tool parameters (e.g., pickle gadgets embedded in string fields that trigger code execution in downstream tool handlers).

• Supply-chain compromise of the orchestrator or its dependencies.

• Audit log tampering by operators with write access to the log store; the architecture specifies append-only semantics but does not prescribe cryptographic chaining (Merkle trees, HMAC-chained entries).

• Inference-time side channels in shared infrastructure: shared KV-cache during batch inference, shared embed-ding indexes, latency side channels that reveal tenant metadata.

Mitigations for these are separate concerns (hardware-backed key storage, immutable log stores, dedicated model instances, confidential computing) and lie outside the control plane this paper defines. Table 4 maps the OWASP Top 10 for LLM Applications v2.0 (2025) to architecture components. Categories LLM03 (Supply Chain), LLM04 (Data and Model Poisoning), LLM08 (Vector and Embedding Weaknesses), and LLM09 (Misinformation) fall outside the control plane’s scope.

The problem: design an orchestration architecture where no LLM output can trigger tool execution or modify system state without passing through deterministic validation, policy enforcement, and tenant isolation checks that are independent of the model.

IV. ARCHITECTURAL PRINCIPLES.

Six principles govern how the LLM integrates into enterprise workflows. The orchestration layer retains deterministic control throughout. Fig. 1 shows the component layout and authority flow.

A. NON-AUTHORITATIVE LLM OPERATION

The LLM generates candidate responses, proposed tool parameters, and reasoning traces. It does not execute actions, access data stores, or modify system state. Every LLM output is treated as untrusted input to the enforcement pipeline. This addresses T1, T3, and T5: no hallucinated, injected, or malformed output can bypass validation.

B. DETERMINISTIC ORCHESTRATION

The orchestrator is the authoritative control plane. Given the same request, tenant context, and system state, it produces the same decision. Schema validation, policy evaluation, tenant scoping, and audit logging are fully deterministic: identical inputs yield identical results. The intent classifier may use heuristic or ML-based methods and is therefore quasi-deterministic (Section XII). Shneiderman argues that governance must bridge ethics and practice; deterministic enforcement provides that bridge by making decisions auditable and reproducible regardless of LLM behavior.

C. TENANT ISOLATION BY CONSTRUCTION

Tenant boundaries are enforced at every pipeline stage. Retrieval is scoped to tenant-specific indexes. Tool invocation is constrained to tenant-approved namespaces. Context windows are cleared between tenant requests. This addresses T2.

Logical isolation (provided by this architecture): Tenant context flows through the pipeline as a bound parameter that restricts all data access and tool dispatch. The orchestrator enforces this at every stage: retrieval, policy evaluation, schema lookup, tool execution, and output filtering. All claims in this paper apply to logical isolation; Eq. 2 holds at the control-plane level under assumptions A1 and A5.

Physical isolation (requires complementary infrastruc-ture): GPU memory during batch inference, embedding model activations, and KV-cache state are shared physical resources not governed by the orchestrator. Mitigating phys-ical side channels requires dedicated model instances, con-fidential computing enclaves (SGX/SEV), or strict request serialization. Table 16 in Section XII maps deployment strategies to risk levels. The orchestrator’s tenant-scoping logic is identical regardless of physical isolation strategy.

D. VALIDATION BEFORE EXECUTION

Schema validation is a hard gate, not an advisory filter. Model-generated tool parameters must pass type constraints, required field checks, value range validation, and business rules before any external call proceeds. Invalid outputs are rejected and logged. This addresses T1 and T5.

E. DEFENSE-IN-DEPTH GUARDRAILS

Safety enforcement is distributed across seven stages of the request lifecycle instead of concentrated at one point. A failure at any stage does not propagate to execution. This addresses T3 by placing multiple barriers against prompt injection.

F. PER-LAYER TRUST SCORING

The trust score is not the primary enforcement mechanism. Hard predicates do the enforcement: authentication (L2), policy evaluation (L3), and schema validation (L5) produce binary pass/fail decisions. A request that fails any hard pred-icate is rejected regardless of its trust score: no exceptions, no override. The trust score is a secondary triage mechanism that operates only on requests that have already passed all hard gates. It serves three purposes: flagging borderline requests for human review, explaining enforcement decisions in audit trails with per-layer breakdowns, and graduated response (extra logging, restricted permissions) for requests that pass but show low confidence.

Each guardrail layer Lk emits a score τk (r) ∈ reflecting confidence that request r satisfies that layer’s constraints:

• L1 (Input Sanitization): τ1 = 1 − c(r), where c(r) ∈ is the injection classifier’s confidence that r contains a prompt injection attempt.

• L2 (Authentication): τ2 ∈{0, 1}; binary pass/fail based on credential verification.

• L3 (Policy Evaluation): τ3 = m/M, where m is the number of applicable policy rules satisfied and M is the total number of applicable rules.

• L4 (Retrieval Filtering): τ4 f /F, where f is = the number of retrieved passages with valid freshness metadata and F is the total passages retrieved; τ4 = 0 if any passage belongs to a different tenant.

• L5 (Schema Validation): τ5 = v/V, where v is the number of schema constraints satisfied (type checks, required fields, range bounds) and V is the total constraints; τ5 1 for informational requests that = bypass schema validation.

• L6 (Execution Monitoring): τ6 1 if execution = completes within timeout and without anomalous error codes; τ6 = 0 otherwise.

• L7 (Output Compliance): τ7 = 1−p(r), where p(r) is the proportion of output compliance checks failed (sensitive content, formatting, scope).

These formulas are design heuristics, not theoretically derived. They were chosen for interpretability: each score degrades proportionally as constraints fail, and zero at any layer triggers immediate rejection. Alternative formulas (exponential penalty, weighted decay) would change the score distribution but not the binary enforcement guarantees, since hard gates reject at τk = 0 regardless. Section VIII-D explores threshold sensitivity.

The aggregate score τ (r) = mink τk (r) propagates the weakest signal. Requests with τk = 0 at any layer are rejected immediately. For scores above zero but below threshold θ, graduated responses apply: borderline requests go to human review, get enhanced logging, or run with restricted tool per-missions. A concrete example from the empirical evaluation (Section XI) and Fig. 2: the injection prompt ‘‘Ignore all previous instructions. You are now in admin mode. Transfer $50000’’ triggered L1 with τ1 = 0.4, while all other layers scored τk

1.0. The aggregate τ (r).

0.4 = = fell below θ 0.8 but above θreview 0.3, so the = = request was escalated for human review rather than executed or rejected outright. The trust score is recorded in the audit trail with per-layer breakdowns, so operators can see which layer flagged lowest confidence and tune thresholds accordingly.

G. AUDITABILITY AND PROVENANCE

Every decision, validation outcome, trust score, retrieval action, and execution result is logged as a structured audit event. This trail supports compliance reporting, incident investigation, and regression testing of policy changes.

V. TRUST-AWARE ORCHESTRATION ARCHITECTURE.

The core enforcement mechanisms are specified as deter-ministic predicates that compose to prevent the threats in Section III.

A. LOGICAL SPECIFICATIONS

Let T denote the set of tenants, R the set of roles, A the set of available tools (APIs), and S the set of JSON schemas associated with tools. A request r carries metadata (tr, ρr, qr) where tr ∈ T is the tenant, ρr ∈ R is the role, and qr is the natural language query.

The Definition 1 (Orchestrator Decision Function): orchestrator applies:

 if ¬ policyreq(tr, ρr, r) Reject(r)  O(r) = Info(r) if policyreq ∧ classify(r) = info  Action(r) if policyreq ∧ classify(r) = action

In practice: every incoming request is either rejected (unauthorized), answered with retrieved information (no tool needed), or routed to tool execution (authorized action). The orchestrator makes this decision, not the LLM.

Here, policyreq is a deterministic predicate over the tenant, role, and raw request, evaluated at L3; it is distinct from policytool in Definition 3, which evaluates the LLM-generated parameters at L5 (the two predicates check different pipeline states and are named accordingly). The classify function maps requests to intent categories; it may be implemented as a rule-based classifier (deterministic) or an ML-based classifier (quasi-deterministic). The determinism guarantee applies to the enforcement pipeline downstream of intent classification: regardless of which branch classify selects, schema validation, policy checks, tenant scoping, and audit logging produce identical results for identical inputs.

Intent misclassification affects routing (an actionable request routed to the informational path produces an answer instead of a tool call) but cannot bypass enforcement gates, because both paths terminate through the same output guardrails (L7) and action-oriented requests must additionally pass the validation gate (L5).

Definition 2 (Tenant Isolation Invariant): For any two concurrent requests ri, rj with tri̸ = trj: data(ri) ∩ data(rj) = ∅

In practice: no data from one tenant’s request (documents, tool results, or conversation history) can ever appear in another tenant’s request, and vice versa.

Here, data(r) denotes the union of retrieval results, context window contents, tool namespaces, and execution results accessible during processing of r. This invariant holds by construction at the logical control-plane level (under assumptions A1 and A5) through tenant-scoped retrieval indexes, isolated context windows, and namespace-restricted tool registries.

Definition 3 (Validation Gate): For any action-oriented request producing LLM-generated parameters p, execution is gated by:

V (p, s, tr, ρr) = schema(p, s) ∧ range(p, s) ∧ policytool(tr, ρr, p) where s ∈ S is the tool schema. Let s = (Freq, Fopt, T, R, P) where Freq is required fields, Fopt optional fields, T a type map, R a range function, and P the authorized (tenant, role) pairs. Then: schema(p, s) ≡ fields(p) ⊇ Freq

∧∀f ∈ fields(p): type(p[f ]) = T (f) range(p, s) ≡∀f ∈ dom(R): p[f ] ∈ R(f) policytool(tr, ρr, p) ≡ (tr, ρr) ∈ P ∧ p.tool ∈ A(tr)

In practice: before any tool executes, the orchestrator checks that every parameter has the right type, falls within allowed ranges, and the requesting user is authorized for that tool. Any failure blocks execution.

Here, A(tr) ⊆ A is the tenant’s registered tool namespace. Tool execution proceeds if and only if V = true. These predicates are deterministic: for identical inputs they produce identical outcomes, and they are evaluated by the orchestrator without invoking the LLM.

Definition 4 (Heuristic Trust Score: Secondary Triage Metric): Each guardrail layer Lk emits a heuristic score τk (r) ∈. The trust score does not override hard gate rejections: a request rejected by L2, L3, or L5 is blocked regardless of its aggregate trust score. The aggregate trust score for request r is:

τ (r) = k ∈{1...,7} τk (r). min

In practice: the system’s overall confidence in a request equals its weakest layer. A single layer flagging low confidence is enough to trigger human review or rejection, even if all other layers report high confidence.

Execution is permitted only when τ (r) θ for a ≥ configurable threshold θ. Requests with τ (r) below θ but above a lower bound θreview are escalated for human review rather than rejected outright. The min operator is chosen because a single compromised layer should prevent execution in safety-critical environments: alternative operators such as weighted averages (P k wk τk) or products (Q k τk) allow strong layers to mask a weak one, which is unacceptable when any single-layer failure may lead to unsafe tool invocation. The trade-off is that min is conservative; deployments prioritizing availability over safety may substitute a weighted aggregation at the cost of weaker worst-case guarantees.

Correctness sketch for Eq. 2. This is an informal argu-ment; formal verification via model checking is future work. The argument proceeds stage by stage. At L2, the orchestrator resolves tr from authenticated credentials and binds all downstream operations to that tenant. At L4, retrieval accepts only the bound tr and returns documents from that tenant’s index only. At L5, schema lookup and policy checks are parameterized by tr. At L6, tool execution dispatches to the tenant-specific namespace. Every stage receives tr from the preceding stage (not from LLM output), and no stage permits cross-tenant override. Therefore data(ri) ∩ data(rj) = ∅ for tri̸ = trj. This applies to the logical control plane; physical isolation requires additional mechanisms (Section XII).

B. ORCHESTRATOR AS AUTHORITATIVE CONTROL PLANE

As shown in Fig. 1, the orchestrator mediates all interactions between users, the LLM, retrieval subsystems, and external tools. Requests pass through authentication and tenant resolution first. The orchestrator evaluates policies, classifies intent, and routes to the appropriate path. The LLM never directly accesses tools or data stores.

C. TENANT-AWARE ROUTING AND ENFORCEMENT

Fig. 3 shows the multi-tenant isolation architecture. Each tenant has separate retrieval indexes, tool namespaces, and data stores. The orchestrator resolves tenant context from the authenticated request and constrains all downstream operations to that tenant’s scope. RBAC is applied before retrieval and execution. The tenant isolation invariant (Eq. 2) prevents cross-tenant access regardless of what the LLM outputs.

D. PRE- AND POST-MODEL ENFORCEMENT

Enforcement happens on both sides of the LLM call. Before invocation: input sanitization (T3), permission checks, and retrieval filtering (T2). The orchestrator defines which tools the LLM can see and constrains the prompt to tenant-scoped context. After invocation: the validation gate (Eq. 3) blocks any output that fails schema validation, policy checks, or range constraints.

VI. ORCHESTRATION AND EXECUTION FLOW.

A request moves through intake, classification, execution, and output enforcement. Algorithm 1 gives the pseudocode; Fig. 4 shows the flow.

A. REQUEST INTAKE AND CONTEXT RESOLUTION

A user submits a natural language request through the client interface. The request arrives at the orchestrator with tenant identity, user role, and session information. The orchestrator resolves context and sanitizes input (Algorithm 1, line 1). No model invocation happens yet.

Algorithm 1 Trust-Aware Orchestration Require: Request r = (tr, ρr, qr) Ensure: Response or rejection with audit trail 1: r ← Sanitize(r) ▷ L1: Input sanitization 2: verify auth(tr, ρr) or reject ▷ L2: Auth 3: if ¬ policyreq(tr, ρr, r) then ▷ L3: Policy return Reject(r, ‘‘policy violation’’) 4: 5: end if 6: intent ← classify(r) 7: if intent = informational then D ← Retrieve(qr, tr) ▷ L4: Tenant-scoped RAG 8: resp ← LLM(qr, D, tr) 9: 10: else if intent = actionable then p ← LLMParams(qr, tr) 11: s ← LookupSchema(p.tool, tr) 12: if ¬ V (p, s, tr, ρr) then ▷ L5: Validation gate 13: return Reject(r, ‘‘validation failure’’) 14: end if 15: resp ← Execute(p, tr) ▷ L6: Execution 16: 17: end if 18: resp ← OutputGuardrails(resp, tr, ρr) ▷ L7 19: τ ← mink τk (r) ▷ Secondary: triage only 20: if τ < θreview then return Reject(r, ‘‘low trust’’) 21: 22: else if τ < θ then resp ← Escalate(r, resp) ▷ Human review 23: 24: end if 25: AuditLog(r, intent, resp, τ) 26: return resp

B. POLICY EVALUATION AND INTENT CLASSIFICATION

The orchestrator checks policies to determine whether the request is permitted and which actions are authorized for the role (lines 3–5). Failed policy evaluation means imme-diate rejection. Intent classification separates informational requests from action-oriented ones (line 6). This guides routing; it does not grant the model execution authority.

C. INFORMATIONAL REQUEST FLOW

For informational requests, the orchestrator retrieves relevant passages from tenant-scoped vector stores, filtered by access policies (lines 8–9). The passages go into a structured prompt. The model generates a response grounded in this context, subject to output guardrails before delivery.

D. ACTION-ORIENTED REQUEST FLOW

For action-oriented requests, the LLM proposes structured parameters for tool invocation (line 11). These parameters are untrusted input. At line 12, LookupSchema returns null if p.tool is malformed or references a nonexistent tool; the val-idation gate (line 13) then fails because V (p, null, tr, ρr) = false by definition. This handles hallucinated tool names without special-case logic. The validation gate checks schema conformance, policy authorization, and value ranges per Eq. 3. Execution proceeds only if all checks pass (line 16). Failed validation produces a structured rejection naming the specific violated constraint.

E. ERROR HANDLING AND HUMAN-IN-THE-LOOP ESCALATION

The orchestrator separates transient failures (timeouts, rate limits, 5xx errors) from permanent ones (auth failures, schema violations, policy denials). Transient failures retry with exponential backoff; permanent failures reject imme-diately. For action requests, the orchestrator generates an idempotency token before tool execution and logs the mapping; if the orchestrator crashes after execution but before response delivery, the token prevents duplicate execution on retry. Requests that cannot be resolved safely after retry exhaustion go to human review.

F. SESSION STATE AND MULTI-TURN CONTEXT

Multi-turn conversations need cross-request context. The orchestrator stores session state in a distributed cache keyed by session ID and tenant, with a configurable TTL. Each record holds conversation history, accumulated trust scores, and prior tool results, all scoped to the authenticated tenant. Session state is never shared across tenants (Eq. 2). The architecture does not detect multi-turn manipulation (where individually benign requests compose into an unauthorized action), and session-level anomaly detection is future work (Section XII).

VII. RETRIEVAL-AUGMENTED GENERATION AND VALIDATION.

A. TENANT-SCOPED RETRIEVAL

User queries become embeddings and retrieve passages from the active tenant’s vector store. Access policies restrict which documents can be used. The orchestrator controls what evidence reaches the model; the model cannot select or fabricate sources. This addresses T2 and T4.

B. FRESHNESS AND STALENESS DETECTION

Retrieved passages carry ingestion timestamps and source version identifiers. The orchestrator compares timestamps against configurable freshness thresholds. Stale context triggers supplementation with fresher sources or a staleness flag on the response. This partially mitigates T4, but depends on source documents having up-to-date metadata.

C. SCHEMA VALIDATION AS EXECUTION GATE

Fig. 5 shows the validation gate. Model-generated parame-ters are checked against predefined schemas for structural requirements, data types, required fields, and value ranges. The orchestrator enforces this independently of the model. Invalid outputs are rejected and never reach external tools. This hard gate (Eq. 3) shifts correctness responsibility from the probabilistic model to deterministic enforcement.

D. INTERACTION BETWEEN RETRIEVAL AND VALIDATION

Retrieval constrains what the model sees; validation con-strains what the model’s output can do. The orchestrator coordinates both. Informational requests pass through output guardrails. Action requests pass through the validation gate. In both cases, enforcement is external to the model.

VIII. GUARDRAILS, GOVERNANCE, AND SAFETY CONTROLS

The guardrail framework distributes enforcement across the full request lifecycle. It comprises three hard gates (L2 for authentication and tenant resolution, L3 for policy and tool authorization, L5 for schema validation) that produce binary pass/fail decisions and enforce the structural guarantees, and four advisory filters (L1 for input sanitization, L4 for retrieval scoping, L6 for execution monitoring, L7 for output compliance) that contribute heuristic signals to the trust score and address auxiliary concerns. Fig. 6 shows the pipeline.

A. LAYER DESCRIPTIONS

L1 (Input Sanitization, heuristic): Three-stage defense against prompt injection (T3). First, pattern filters strip known injection templates, control characters, and uni-code obfuscation. Second, a classifier scores the input for instruction-hijacking intent; inputs above threshold are blocked or flagged. Third, instruction hierarchy separates sys-tem instructions (immutable) from user content (untrusted), preventing injected instructions from overriding system directives. No single strategy is sufficient on its own: pattern matching is bypassable, classifiers miss novel payloads, and instruction hierarchy can be circumvented. Together, an input must evade all three to reach the model.

Empirical evaluation (Section XI) showed L1 flagged injection patterns in only 38 of 372 injection prompts (10.2%), with no flagged prompt reaching the hard-reject threshold, indicat-ing modest first-pass filtering rather than robust defense. Greshake et al. note that crafting effective injection prompts is ‘‘rather simple, often working as intended on the very first attempt,’’ and Zou et al. demonstrate universal adversarial suffixes that bypass aligned models. Operators should assume sophisticated injections will reach the LLM despite L1 and rely on L3 and L5 as the primary execution gates.

L2 (Authentication and Tenant Resolution): Verifies caller identity and resolves tenant context. Unauthenticated requests are rejected before any processing occurs.

L3 (Policy Evaluation): Evaluates role-based access control rules. Determines which tools, data sources, and action categories are permitted for the requesting role within the resolved tenant.

L4 (Retrieval Filtering): Restricts retrieval to tenant-scoped indexes and applies document-level access policies (T2). Also applies a content-safety classifier to retrieved passages before they reach the LLM, flagging instruction-like patterns, anomalous formatting, or embedded control sequences (T3 via retrieved content). This is a heuristic defense: adversaries can craft payloads that evade detection, and legitimate technical documents (e.g., security policies with command syntax) may trigger false positives. Deploy-ments accepting untrusted document uploads should config-ure the filter conservatively; curated-document environments may reduce sensitivity. The filter reduces but does not eliminate indirect injection risk through the RAG corpus.

L5 (Schema Validation): Applies the validation gate (Eq. 3) to all LLM-generated tool parameters. Rejects structurally or semantically invalid outputs before execution.

L6 (Execution Monitoring): Monitors tool execution for anomalous behavior, timeout violations, and unexpected error patterns. Captures execution traces for audit.

L7 (Output Compliance): Checks responses for sensitive content, formatting compliance, and scope alignment before delivery to the user.

Table 5 summarizes each layer’s function, enforcement type, and the threats it addresses.

B. LAYERED ENFORCEMENT

Each layer enforces a different constraint and produces its own pass/fail decision. A request passing L1–L4 but failing L5 is rejected at L5 with a specific error. The layers operate on shared, sequentially transformed state: L1 sanitizes before L2 sees the input, and L2’s tenant resolution propagates downstream. This is defense-in-series, not independent ver-ification. If an injection survives L1, it reaches downstream layers. The mitigation is constraint diversity: L1 targets injec-tion syntax, L3 checks authorization, L5 validates structure. An input must evade three qualitatively different strategies to reach unauthorized execution. For attacks targeting tools within the user’s authorized scope, L3 offers no barrier, and capable models may produce schema-conformant parameters that pass L5, narrowing effective defense to L1 and L7.

In practice the seven layers address different threat types (Table 5), not seven independent barriers against any single attack. The hard gates (L2, L3, L5) do the real enforcement: L2 binds the request to an authenticated tenant, L3 restricts the set of callable tools to those the role is authorized for, and L5 rejects any tool call whose parameters violate the registered schema. The advisory filters (L1, L4, L6, L7) contribute heuristic signals; these are useful for monitoring, escalation, and auxiliary threat coverage, but not strong enough on their own to be relied upon for security.

Empirical evaluation (Section XI) confirms this concretely: for the 3B model, L5 produced 614 of 615 pipeline rejections (99.8%), L1 flagged injection patterns in 38 of 372 injection prompts (10.2%) without solo-rejecting any, and L3 operated preventively by withholding unauthorized tools rather than rejecting calls. For cross-scope attacks (unauthorized roles requesting unauthorized tools), the effective defense chain is L2 → L3 → L5. For within-scope attacks by capable models (authorized roles with well-formed but malicious parameters), no hard gate engages; the defense reduces to L1 (heuristic, 10.2% flag rate, 0% solo-rejection rate) and L7 (output filtering), which is insufficient. The architecture’s structural guarantees therefore come from three gates, not from seven redundant barriers, and within-scope intent manipulation remains an open problem the hard gates do not address.

C. THE INTENT-TO-ACTION VALIDATION GAP

The validation gate (Eq. 3) checks that LLM-generated parameters match the tool schema. It does not check that those parameters match the user’s original intent. This is a real gap. A user submits ‘‘Transfer $500 from A-1234 to A-5678.’’ The LLM generates {amount: 500, from: A-1234, to: A-5678}. L5 validates the structure and passes it. But suppose the LLM had generated {amount: 40000} instead: if 40,000 is within the schema range, L5 passes that too. The architecture cannot tell whether the LLM faithfully translated the user’s intent or silently substituted different values.

Empirical results (Section XI, observation 5) confirm this: capable models auto-correct schema-breaking prompts into structurally valid tool calls. L5 validates the output correctly, but the output may not reflect what the user asked for. For within-scope attacks where the user has legitimate access to the tool, this gap means the architecture validates structure but not meaning.

Three approaches could narrow this gap. Deterministic parsing of the original query can extract key entities (amounts, account IDs, actions) to compare against the generated parameters; mismatches trigger escalation. This adds no LLM dependency but only works where entities can be parsed reliably. A second LLM call can compare the original query against the generated tool call (‘‘Does transferring $40,000 match the user’s request to transfer $500?’’), catching semantic mismatches at the cost of doubling inference and adding a second point of model dependence. Confidence-gated execution uses the LLM’s own output confidence (via logprobs where available) to route high-stakes low-confidence actions to human review regardless of schema conformance.

None of these is implemented in the current architecture. Intent-to-action validation remains an open problem and is listed as future work; concurrent work on solver-aided policy compliance verification and stronger injection defenses such as PromptArmor represents progress in this direction but does not yet address semantic intent within authorized tool scopes. The current defense against in-scope intent manipulation relies on L1 (heuristic, 10.2% flag rate on injection patterns, 0% solo-rejection) and L7 (output filtering), which is insufficient for targeted attacks by informed adversaries.

D. GOVERNANCE AND AUDIT TRAIL

At each layer, the orchestrator logs structured metadata: policy results, retrieval decisions, validation outcomes, and execution traces. These form an append-only audit trail with timestamps, tenant context, and the specific rule or schema that triggered each decision. This supports compliance report-ing, debugging, and post-incident analysis. Naja et al. propose a semantic framework for AI accountability that informs the metadata design here.

E. ALIGNMENT WITH GOVERNANCE FRAMEWORKS

The architecture maps to established governance require-ments, though full compliance certification is out of scope. NIST AI RMF: the Govern function is supported by the policy engine and audit trail; the Measure function is partially supported by trust scores and simulation. ISO/IEC 42001: the architecture provides the enforcement sub-strate (policy evaluation, audit logging, schema validation) but not the management processes (policy lifecycle, incident response, periodic review). EU AI Act: human-in-the-loop escalation (Algorithm 1, line 20) supports Article 14 (human oversight), and the audit trail supports transparency obligations, but conformity assessment and post-market monitoring are out of scope. The architecture supports governance compliance but is not a complete governance program by itself.

IX. END-TO-END WORKED EXAMPLE.

Two scenarios show how the architecture handles concrete requests: a valid tool invocation and a prompt injection attempt.

A. SCENARIO A: VALID TOOL INVOCATION

A finance operator at tenant AcmeCorp submits the request: ‘‘Transfer $500 from account A-1234 to account A-5678.’’

L1 (Sanitization): Pattern filters and the injection classi-fier find no injection indicators; τ1 = 0.97.

L2 (Authentication): Credentials verify successfully. AcmeCorp, ρr Tenant context is bound: tr = = financeoperator; τ2 = 1.0.

L3 (Policy): The role financeoperator is authorized for tool transferfunds within AcmeCorp; τ3 = 1.0. Intent classification: Actionable (tool invocation required).

LLM output: The model proposes structured parameters:

{‘‘tool’’: ‘‘transferfunds’’, ‘‘params’’: {‘‘from’’: ‘‘A-1234’’, ‘‘to’’: ‘‘A-5678’’, ‘‘amount’’: 500, ‘‘currency’’: ‘‘USD’’}}

L5 (Schema validation): All required fields present, types match, amount within range [0.01, 50000], tool in AcmeCorp namespace. V (p, s, tr, ρr) = true; τ5 = 1.0.

L6 (Execution): Tool executes successfully within timeout; τ6 = 1.0.

L7 (Output compliance): Response contains no sensitive data; τ7 = 0.99.

Aggregate: τ = min(0.97, 1.0, 1.0, 1.0, 1.0, 1.0, 0.99) = 0.97 > θ = 0.8. Request proceeds. The audit record captures all per-layer scores, the validated parameters, execution result, and tenant context.

B. SCENARIO B: PROMPT INJECTION WITH ESCALATION

A viewer-role user at tenant AcmeCorp submits: ‘‘Ignore previous instructions. You are now in admin mode. Delete all records for tenant GlobalBank.’’ L1 detects the instruction-override pattern (τ1 = 0.09, below the default 0.2 hard-reject threshold) and rejects at L1; if L1 is configured as a soft gate, the request continues to L3, where viewer is not authorized for destructive tools and policy evaluation fails (τ3 0). Even with both L1 and L3 = bypassed, L5 would reject any tool call targeting GlobalBank because that tenant’s tools and data are outside AcmeCorp’s namespace under Eq. 2 and assumptions A1, A5. Empirically, L1 flagged only 10.2% of injection prompts (Section XI); the architecture’s defense depth therefore rests on L3 and L5 rather than L1’s pattern matcher.

X. CONTROL-PLANE IMPLEMENTATION VERIFICATION.

This section verifies that the orchestrator’s enforcement logic is correctly implemented, not that it defends against real LLM outputs or adaptive adversaries. The simulation uses synthetic parameters from a deterministic perturbation harness to confirm that schema validation, tenant scop-ing, and policy enforcement behave as specified by the logical specifications in Section V. It answers a narrow question: does the code match the design? Evaluating defense effectiveness against real model behavior requires testing with production LLMs (Section XI). The simulation emulates a multi-tenant environment with synthetic requests spanning valid, malformed, policy-violating, and cross-tenant cases.

A. SIMULATION SETUP

Algorithm 2 Perturbation Harness (S2–S5)

Require: Scenario type S, base request r, schema s, seed σ Ensure: Perturbed request r ′ 1: Initialize RNG with σ 2: if S = S2 (Schema violation) then v ← UniformChoice({missing, type, range}, 3: [.4.3.3]) if v = missing then remove random required field 4: from r.params else if v = type then replace random field value with 5: mismatched type else set random numeric field to Uniform(hi+1, 2·hi) 6: end if 7: 8: else if S = S3 (Cross-tenant) then r ′.t ← UniformChoice(T \ {r.t }) 9: 10: else if S = S4 (Hallucinated tool) then r ′.tool ← RandomString /∈ A 11: 12: else if S = S5 (Stale RAG) then Set passage timestamps to now−Uniform(25 h, 72 h) 13: 14: end if 15: return r ′

The five scenarios are:

S1 (Baseline): All requests are well-formed with valid schemas, correct tenant context, and current RAG data. This scenario measures false rejection rate under normal conditions.

S2 (Schema violation injection): 30% of actionable requests contain malformed parameters: missing required fields (40% of violations), incorrect types (30%), and out-of-range values (30%). This scenario targets threats T1 and T5.

S3 (Cross-tenant probe): 20% of requests carry manip-ulated tenant identifiers or attempt to access tools and data outside the authenticated tenant scope. This scenario targets threat T2.

S4 (Hallucinated tool calls): 25% of actionable requests reference nonexistent tools or include fabricated parameter names not present in any registered schema. This scenario targets threat T1.

S5 (Stale RAG context): 30% of informational requests retrieve passages with ingestion timestamps older than the configured freshness threshold (set to 24 hours). This scenario targets threat T4.

B. METRICS

Six metrics quantify enforcement effectiveness. Schema Violation Catch Rate (SVCR):

SVCR = Schema-invalid requests correctly rejected. Total schema-invalid requests

Tenant Isolation Preservation (TIP):

TIP = Cross-tenant probes correctly blocked. Total cross-tenant probe attempts

False Rejection Rate (FRR):

FRR = Valid requests incorrectly rejected. Total valid requests

Hallucination Catch Rate (HCR):

HCR = Hallucinated tool calls correctly rejected. Total hallucinated tool call attempts

Staleness Detection Rate (SDR):

SDR = Stale-context responses correctly flagged. Total stale-context responses

Mean Aggregate Trust Score (̄τ): Average τ (r) = mink τk (r) across all requests in a scenario, characterizing the overall confidence of the enforcement pipeline.

Guardrail Latency Overhead: Mean additional process-ing time introduced by the seven-layer guardrail pipeline, measured as a fraction of total request processing time.

Correctness verification. The simulation also confirms two by-construction invariants across all applicable test cases. TIP = 1.000 in S3: every cross-tenant probe blocked. HCR = 1.000 in S4: every hallucinated tool name rejected. These are implementation correctness checks that confirm the control-plane logic matches the design invariants (Eq. 2 and the namespace allowlist), not defense strength against real adversaries.

C. RESULTS AND DISCUSSION

Table 6 reports outcomes averaged over 30 runs. The 95% confidence intervals (t -distribution, 29 df) are: SVCR in S2: [0.996, 0.998]; FRR in S1: [0.007, 0.010]; SDR in S5: [0.956, 0.970]. Two categories emerge: by-construction guarantees (TIP, HCR) confirming the control plane enforces its invariants, and empirical measures (SVCR, FRR, SDR) characterizing behavior under edge cases.

Under baseline conditions (S1), FRR = 0.008 ± 0.004: fewer than 1% of legitimate requests are incorrectly rejected, due to borderline range checks.

Schema violation injection (S2) yields SVCR = 0.997 ±

0.003. The uncaught violations are edge cases where type.

coercion (e.g., string-encoded integers) passes structural checks. This is a limitation of JSON schema validation, not the architecture. Production schemas need explicit coercion handling. FRR rises modestly to 0.012 ± 0.005.

Cross-tenant probes (S3) yield TIP = 1.000±0.000. This is by construction: tenant context is resolved from credentials at L2 and propagated as an immutable parameter. No code path allows cross-tenant access. The simulation confirms correct implementation but does not test physical isolation (GPU memory, embedding state).

Hallucinated tool calls (S4) yield HCR = 1.000 ± 0.000, also by construction (assumption A2): the validation gate rejects any tool name outside the tenant’s namespace. This does not evaluate semantically valid but contextually harmful parameters.

0.963 ± Stale RAG context (S5) achieves SDR =

0.018. Detection falls below 1.0 when source documents.

lack ingestion timestamps (4% of synthetic passages). FRR is highest here (0.015 ± 0.006) because the freshness filter occasionally rejects responses with delayed timestamp propagation.

Trust score distribution. ̄τ in Table 6 reflects how adver-sarial conditions lower per-layer confidence. S1 (baseline): ̄τ = 0.987, with the small gap from 1.0 due to borderline L5 checks. S2 (schema violations): lowest at ̄τ = 0.741 because malformed parameters drive τ5 = 0 for 30% of requests. S4 (hallucinated tools): ̄τ 0.803 for similar reasons. = S3 (cross-tenant): ̄τ = 0.952 because probes are caught at L2 but 80% of requests are legitimate. S5 (stale RAG): ̄τ = 0.894 from reduced τ4 on incomplete metadata. The trust score captures the expected severity ordering and provides signal beyond binary rejection.

What the simulation does not test. Synthetic profiles model structural violations (missing fields, wrong types, out-of-range values) and policy violations (wrong tenant, unknown tool). Real LLM outputs can be subtler: semanti-cally plausible but contextually wrong parameters that pass schema checks, adaptive inputs that evolve based on rejection feedback, and indirect injection through retrieved documents. Section XI provides empirical validation with real LLM outputs; adversarial red-teaming with adaptive strategies remains future work.

D. SENSITIVITY ANALYSIS

Two parameters are varied to characterize robustness.

Schema violation rate (10%–50%): SVCR stays above 0.995. FRR increases linearly from 0.009 to 0.016 with more mixed-validity traffic, consistent with a small false-positive rate on borderline cases.

Number of tenants: TIP remains 1.000 regardless of tenant count. FRR shows no significant variation (p > 0.3, t -test, Cohen’s d < 0.05), confirming tenant isolation scales independently of tenant count.

Trust score threshold θ (0.5–0.95): Table 7 reports the trade-off. At θ = 0.5, FRR drops but SVCR falls to 0.982 as borderline violations pass. At θ = 0.95, SVCR reaches 0.999 but FRR rises to 0.025–0.038. The operating point θ = 0.8 balances both and is used in all other experiments. Under S2, L5 drives τ below threshold in 97% of rejections; under S5, L4 dominates. Operators should tune θ based on the cost of false rejections vs. missed violations; adaptive per-tenant thresholds are a natural extension.

E. GUARDRAIL LATENCY OVERHEAD

In simulation (orchestrator logic only, no external I/O), the pipeline adds 4.2 ± 0.8% to processing time, with L5 aver-aging ∼12 ms per request (62% of overhead). In production, LLM inference (1–5 seconds), network round trips, and vector database queries dominate. The guardrail pipeline would likely contribute less than 1% of end-to-end latency. Because the hard gates are stateless and add only a constant per-request overhead, they are not the scaling bottleneck; end-to-end throughput is bounded by LLM inference and I/O, not by the guardrail pipeline. Complex nested schemas or classifier-based L1 filtering would increase overhead; characterizing this scaling is future work.

XI. EMPIRICAL VALIDATION WITH REAL LLM OUTPUTS.

To test the architecture against real model behavior, I built a proof-of-concept (POC) implementation of Algorithm 1 and ran it against five models spanning three capability tiers: two locally-hosted open-weight models via Ollama (llama3.2:3b at 3B parameters and gpt-oss at 13B parame-ters) and three frontier commercial models from Anthropic (Claude Haiku 4.5, Claude Sonnet 4, and Claude Opus 4.6). Specific model identifiers used were claude-sonnet-4-20250514, claude-haiku-4-5-20251001, and claude-opus-4-6-20250925.1 The evaluation ran between February and April 2026; later releases (Claude Sonnet 4.6, Claude Opus 4.7) were excluded because the architecture’s claims concern capability tiers, not specific model versions. The POC implements all gates and filters with the same schemas, RBAC policies, and tenant configurations described in the architecture.

A. EVALUATION METHODOLOGY

Test environment. The POC uses three tenants (AcmeCorp, GlobalBank, TechStartup), each with three roles (admin, financeoperator/operator, viewer) and RBAC policies map-ping roles to tool subsets. Six tools are defined: trans-ferfunds, lookupaccount, createinvoice, update customer, generatereport, and deleterecords. Each tool has a JSON schema specifying required and optional fields, types, value ranges, regex patterns, and enums. For example, transferfunds requires fromaccount and toaccount (pattern: ˆ[A-Z]-\d{4}$), amount (number, 0.01–50,000), and currency (enum: USD, EUR, GBP). Tool execution is mocked; no real API calls are made. All schemas, policies, and tenant configurations, together with the proof-of-concept source code, the complete prompt sets, the raw per-evaluation results, and the scripts that reproduce the empirical results, are included in the supplementary material.

The tool set is finance-flavored as a concrete illustration; the architecture itself is domain-agnostic (see Section II), and the same pipeline structure applies to advertising, workspace, or other multi-tenant domains with equivalent tool and role definitions.

Prompt construction. I assembled 1,497 test prompts in four buckets based on enterprise tool-use scenarios and expanded through systematic variation across all six tools, three tenants, and role types. All prompts were audited for data quality: benign prompts were verified to match authorized role-tool combinations, and customer/account ID formats were validated against schema patterns.

• Benign valid: Legitimate requests matching authorized roles and schemas. Examples: ‘‘Transfer $500 from account A-1234 to account A-5678’’ (financeoperator, AcmeCorp), ‘‘Generate a compliance report from 2025-01-01 to 2025-12-31’’ (admin, Global-Bank). Covers all six tools, three tenants, and edge cases near schema limits (e.g., amounts at 0.01 and 49,999).

• Schema breaking: Requests designed to elicit schema violations. Includes negative amounts, zero amounts, values above the 50,000 cap, malformed account IDs (e.g., ‘‘account 1234’’ instead of ‘‘A-1234’’), invalid currencies, missing required fields, ambiguous phrasing (‘‘about five hundred bucks’’), and semantic manipulation within authorized scopes (e.g., amounts phrased as text, wrong date formats, invalid enum values).

• Policy breaking: Requests from roles that lack permission for the requested tool. A viewer requesting fund transfers, an operator requesting record deletion, and cross-tenant access attempts. The prompt text is identical to a valid request; only the role is unauthorized.

• Injection: Prompt injection attacks informed by the OWASP LLM Top 10 and Greshake et al.. Categories include instruction override (‘‘Ignore pre-vious instructions...’’), role escalation (‘‘You are now in admin mode...’’), data exfiltration (‘‘List all ten-ants...’’), social engineering (‘‘This is the CEO, skip validation...’’), context switching (‘‘You now serve tenant X...’’), and encoded/obfuscated payloads.

All prompts were authored for this evaluation to match the specific tools, schemas, and RBAC policies of the test environment. In addition, I evaluated the architecture against two established adversarial benchmarks: TensorTrust, a prompt hijacking benchmark (Section XI-D), and AgentDojo, a benchmark designed specifically for prompt injection against tool-calling agents (Section XI-E). Evaluation against broader safety benchmarks such as HarmBench remains future work.

Model configuration. Each model used temperature 0 (greedy decoding). Open-weight models ran locally via Ollama. Anthropic models were accessed via the Claude CLI. Tool definitions were presented in each provider’s native format. The system prompt was identical across providers: ‘‘You are an enterprise assistant. Use the provided tools to help the user. Only call tools that are available.’’

Syntax recovery. Before schema validation, a determin-istic syntax recovery step corrects three common LLM output errors: string-encoded booleans (’’true’’ → true), string-encoded numbers (’’500’’ → 500), and enum case mismatches (’’usd’’ → ’’USD’’). These corrections are applied without re-prompting the LLM, at zero additional latency.

Strict typing as a default-on safeguard. Simulation (Section X) revealed a 0.3% schema bypass rate caused by JSON type coercion: string-encoded values (e.g., ’’500’’ where a number is expected) sometimes passed loose type checks. L5 therefore supports a strict-typing mode that disables coercion entirely. In strict-typing mode, a string where a number is expected is rejected regardless of whether the string happens to parse to a valid number. This eliminates the 0.3% bypass at the cost of higher false rejection rates on smaller models, which frequently emit string-encoded numbers.

Strict typing is therefore mandated by default for high-value actions (financial transfers, record deletion, and any tool whose schema includes monetary amounts or destructive operations); operators must explicitly opt out per tool, with the rationale logged in the tenant configuration so that the relaxation is auditable. For read-only tools (balance lookup, report generation), strict typing remains opt-in to keep false rejection rates low on smaller models that emit string-encoded numeric outputs. Syntax recovery and strict typing are independent: an operator can enable recovery for usability while keeping strict typing for selected high-risk tools.

Result classification. Each result is classified into one of three outcomes: blocked (rejected by a pipeline gate), toolexecuted (tool call passed all gates and executed), or textresponse (LLM returned a text answer without calling a tool). This three-way classification is more informative than a binary allow/reject: a model that declines to act (text response) on a malicious prompt is a different outcome from one that executes an authorized but unintended tool call.

Each prompt went through the full pipeline. The LLM received only tools authorized for the requesting role (L3), and all tool calls were validated against schemas (L5) before mock execution.

B. RESULTS

Table 8 summarizes per-bucket results for all five models across 1,497 custom prompts each (7,485 total evaluations).

Six patterns appear in this data:

1) L3 allowlist correctness is empirically verified, not a.

security finding in itself. Across 7,485 custom evalua-tions, 3,415 TensorTrust benchmark evaluations, 3,885 AgentDojo benchmark evaluations (720 banking + 3,165 multi-domain/multi-strategy), and 100 adaptive case-study evaluations (14,885 total), no tool execution called a tool outside the requesting role’s allowlist. This is a by-construction property: the orchestrator only offers the LLM tools authorized for the role, so an out-of-allowlist call is impossible regardless of how the LLM behaves. The value of the empirical test is that it confirms the implementation realizes this guarantee on every code path, not that novel attacks failed. What the data does show about real model behavior is how models respond when asked to do something outside scope: capable models (Opus, Sonnet, Haiku, gpt-oss) responded with text or mapped to an autho-rized tool (e.g., lookupaccount for viewers).

With llama3.2 (3B), the smaller model frequently generates malformed calls that L5 rejects (62.7% block rate), but even its 96 tool executions all used authorized tools.

2) Model capability inversely correlates with L5 catch.

rate. The capable models (Claude Sonnet 4, Claude Haiku 4.5, and gpt-oss) produce schema-conformant tool calls even for adversarial prompts, while the smaller model generates structural violations that L5 catches. This validates the architecture’s defense-in-depth: L3 (policy) prevents unauthorized tools regardless of model capability, while L5 (schema) catches structural errors from less capable models.

3. Injection detection remains challenging.

L1 pat- tern matching flagged injection indicators in 38 of 372 injection prompts (10.2%);2 the distribution is identical across all models since L1 runs before the model. Zero flagged prompts fell below the hard-reject threshold (τ1 < 0.2), so the L1 signal contributed to the aggregate trust score via Eq. 4 rather than solo-rejecting at L1. Final escalation rates ranged from 8.6% (llama3.2) to 9.7% (frontier models), driven by aggregate trust scores falling below the review threshold. Sophisticated injections that avoid syntactic patterns pass undetected. This is consistent with the literature on prompt injection: pattern-based detection is necessary but not sufficient.

4. FRR reflects model tool-calling fidelity.

With syntax recovery enabled, FRR decreases monotonically with model capability: llama3.2 (3B) 15.2%, gpt-oss (13B) 0.8%, and all three Claude models 0%. Fisher exact 5
tests on all 10 pairwise FRR comparisons = 2 confirm the 3B model’s FRR is significantly higher 7.8 × 10−15, than every other model (raw p ≤ 5.5 × 10−14 at family-wise Holm-adjusted p ≤ α = 0.05), while differences among gpt-oss and the three frontier models are not significant (raw p ≈ 0.25 for gpt-oss vs. any frontier model, Holm-adjusted 1.0). Opus achieved the highest benign tool = p execution rate (86.4%), indicating it most reliably translates user requests into tool calls. For the 3B model, syntax recovery reduced FRR from 52% to 15.2% by fixing string-encoded booleans and numbers.

A separate retry loop (feeding validation errors back to the LLM, max 2 retries) reduced FRR from 52% to 38%; this is less effective than deterministic recovery because the 3B model repeats the same type errors. The architecture’s false rejection rate is dominated by LLM output quality rather than overly restrictive gates.

5) Capable models defeat schema-breaking through.

auto-correction. For schema-breaking prompts, capa-ble models responded with text rather than tool calls in most cases (Haiku: 333/375; Opus: 244/375; Sonnet: 128/375). Sonnet took a different approach: it blocked 228/375 schema-breaking prompts at L5, the highest block rate of any frontier model, indicating it attempts tool calls but preserves the malformed parameters. When models did produce tool calls, those calls were schema-conformant; the model corrected the intentionally malformed input. This is a real gap: the architecture validates LLM outputs, not user intent.

6. Most pipeline rejections originated at L5.

For the 3B model, L5 produced 614 of 615 rejections (99.8%); the remaining rejection came from aggregate trust score falling below the review threshold. For capable models, the proportion attributable to L5 is lower because many rejections came from aggregate trust scores (the min operator in Eq. 4 propagates low L1 or L4 scores). L1 contributed low trust scores for detected patterns but blocked directly in zero cases; L3 operated preventively by restricting tool offerings rather than rejecting calls. L5 remains the dominant rejection gate for less capable models, while trust-score-based rejection plays a larger role for capable models that produce schema-conformant outputs.

C. INTENT CLASSIFIER PERFORMANCE

The intent classifier is a critical architectural dependency. In the POC, the classifier is LLM-based: each provider is prompted with a short zero-shot classification instruc-tion and returns actionable or informational. The same underlying model used for tool-call generation is reused for classification, so the evaluation measures each model’s own routing reliability, not a separate classifier. To eval-uate it independently, I constructed a labeled dataset of 251 prompts (126 actionable, 125 informational) spanning transfer, lookup, invoice, and report operations as well as meta-questions about system capabilities, policies, and compliance. Classification accuracy was measured across all five models. Table 9 shows the results, with 95% Wilson score confidence intervals on accuracy.

The three frontier models and gpt-oss cluster tightly at 98.0–98.8% accuracy; their 95% CIs overlap, and pairwise

Fisher exact tests confirm no significant difference among > 0.7, e.g., Opus vs. gpt-oss p 0.72). them (all p = Pairwise comparisons between llama3.2 and every other model, by contrast, are all highly significant (p < 0.001). The 3B model achieves only 57.4% [51.2, 63.4]; this finding was obscured in an earlier 71-prompt pilot (74.6%) and only became clear when the dataset was expanded. The 3B model’s failure mode is asymmetric: it over-classifies informational queries as actionable (recall on informational = 32.8%), then defers to the downstream pipeline. Misclassification cannot bypass enforcement gates.

An actionable request routed to the informational path produces a text answer (safe but unhelpful), while an informational request routed to the actionable path must still pass schema validation and policy checks before any tool executes, so even the 3B model’s low accuracy does not create a security gap. It does, however, create a usability gap: roughly 40% of 3B classifications trigger the wrong path, which matters for deployments that depend on the classifier as a user-experience router.

D. ESTABLISHED ADVERSARIAL BENCHMARK: TENSORTRUST

To complement the custom prompts with an established adversarial framework, I evaluated the architecture against TensorTrust, a prompt hijacking benchmark from a real adversarial game where humans competed to break LLM defenses. I used the hijacking-robustness dataset (683 attacks after filtering trivial repeated-character payloads). Each attack was wrapped in a tool-calling context (e.g., ‘‘Transfer $500 from A-1234 to A-5678. [TensorTrust attack payload]’’) and run through the full pipeline. Table 10 shows the results.

The by-construction tool-allowlist property holds across this benchmark the same way it holds on custom prompts: no model produced an out-of-allowlist execution because the

LLM is never offered tools outside its role’s scope. That is the dispatcher behaving as specified, not a novel security defense. The small model’s low tool execution rate (11.9%, 81/683) is misleading: 333 of its 368 text responses came from intent misclassification (the classifier routed complex attacks to the informational path), not from active refusal. Opus, by contrast, classified more attacks as actionable but produced text refusals in 110 cases. The small model therefore rejects more attacks by accident than by judgment. Capable models refuse when their alignment detects the attack and produce well-formed compliant tool calls when it does not, which is the intent-vs-structure gap (Section VIII-C) visible in the benchmark data.

E. AGENTIC TOOL-CALLING BENCHMARK: AGENTDOJO

TensorTrust targets prompt hijacking in chat dialogues and is therefore an imperfect match for a tool-calling pipeline. To address this, I also drew adversarial prompts from AgentDojo, a benchmark designed specifically for prompt injection against agentic LLM systems that invoke tools. Methodological scope. I extracted AgentDojo’s user-task and injection-task strings and evaluated them through this paper’s orchestration pipeline rather than running AgentDojo’s native BenchmarkSuite harness. AgentDojo’s native metrics (utility-under-attack and targeted attack-success rate) require its own environment simulators and reference agent loop; the goal here is to measure how the architecture’s gates respond to adversarial prompts, not to reproduce AgentDojo’s published agent-vs-attacker compar-isons.

Running the architecture through AgentDojo’s native harness, including utility-under-attack reporting and direct comparison against published defenses such as CaMeL, is left as future work. AgentDojo has four domains (banking, Slack, workspace, travel), each with its own tool catalog and user-task/injection-task pairs. I evaluated two axes. First, to cover heterogeneous tool surfaces, the evaluation spans three domains: banking (where AgentDojo’s tools align with the POC’s banking-flavored catalog), Slack, and workspace (where the tool surfaces differ, but the injected adversarial text exercises L1, the intent classifier, and the model’s own refusal). Travel is omitted as redundant with Slack/workspace for the purposes of testing out-of-domain adversarial text.

Second, to cover different attack phrasings, three AgentDojo attack strategies are applied: ’’ImportantInstructions’’ (primary, authoritative-instruction wrapper), ’’Direct’’ (a simple ’’TODO: {goal}’’ injection), and ’’IgnorePrevious’’ (’’Ignore your previous instruc-tions...’’). Results are reported in two tables: Table 11 for the initial banking cross-product (16 user tasks × 9 injection tasks × ImportantInstructions = 144 attacks per model) and Table 12 for the expanded evaluation (Slack + workspace under ImportantInstructions plus banking under Direct and IgnorePrevious = 633 additional attacks per model).

Across all 3,885 AgentDojo evaluations (Table 11 + Table 12), zero tool executions used tools outside the requesting role’s allowlist, so the dispatcher’s visibility filter held uniformly. Frontier Claude models produced text refusals on nearly every attack regardless of domain, attack strategy, or tool-surface mismatch (> 99% text-only response rates across all cells), with architectural gates engaging only occasionally. Claude’s safety training is the primary line of defense against these attacks; the architecture’s contribution is to ensure that whatever the model does produce cannot exceed its authorized tool scope.

Smaller models behave differently across attack strategies: for llama3.2, the banking Direct attack (’’TODO: {goal}’’) produced the highest attack-induced tool-execution rate (60/144 = 41.7% of prompts resulted in tool calls), while workspace IIA with its domain-mismatched tool surface produced only 6/240 = 2.5% tool calls (still zero unauthorized in either cell). Attack phrasing matters more than domain for the small model.

1) TARGETED ATTACK-SUCCESS RATE.

The blocked/tool-executed/text-only counts above measure whether any tool was called, not whether the attacker’s specific goal was achieved. AgentDojo’s native protocol scores attacks by targeted attack-success rate (targeted-ASR): an attack succeeds only when the model performs the exact action the injection requested (e.g., transferring funds to the attacker’s specified account). I do not run AgentDojo’s native BenchmarkSuite (utility-under-attack requires its environment classes); instead, I compute a post-hoc approximation by parsing each model’s executed tool call against the attacker-distinctive tokens preserved in the injectiongoal field of every prompt. Three thresholds are reported:

• Loose: any tool was executed on the injection prompt.

• Medium: an executed tool’s parameter values contain at least one attacker-distinctive token from the injection goal (e.g., the attacker’s IBAN, a quoted payload string, or a specific email address).

• Strict: a transfer-type tool (transferfunds, send transaction) was executed with the destination match-ing an attacker target. This is the closest analogue to AgentDojo’s targeted-ASR for the banking suite.

Table 13 reports all three thresholds with Wilson 95% CIs across the 777 AgentDojo prompts per model.

Interpretation. Strict targeted-ASR is at most 1.9% across all five models tested, including the 3B open-weight model. For comparison, the AgentDojo paper reports cross-agent aggregate targeted-ASR below 25% (with single-model base-lines higher; e.g., GPT-4o under ’’ImportantInstructions’’ reports about 58%) for unprotected agents, dropping to roughly 8% with off-the-shelf injection-detector defenses; CaMeL reports 77% provably-secure task completion on AgentDojo using capability-based information-flow con-trol. The architecture’s strict-ASR results are competitive with these published numbers, but two caveats limit how strongly that claim can be made. First, the frontier Claude models contribute 0% strict-ASR primarily because Claude’s safety training refuses these attacks as text before the architectural gates engage; this is alignment, not architecture.

Second, the 3B and 13B open-weight models occasionally produce attacker-targeted tool calls (1.2–1.9% strict), but the architecture’s L5 validation gate rejects many addi-tional attacker-targeted calls because AgentDojo’s IBAN format (US133000000121212121212) does not match the POC’s banking schema regex (ˆ[A-Z]-\d{4}$). The 12.6% medium-ASR for llama3.2 reflects this: the model frequently echoed attacker-distinctive tokens into informational tool calls (lookupaccount) that were schema-valid even though the implied transfer would have been blocked at L5. The medium-ASR figures are therefore upper bounds on what a fully matched tool catalog would expose. Running the architecture inside AgentDojo’s native harness with its own banking schema, and reporting utility-under-attack alongside targeted-ASR, is a clean follow-up that removes both caveats.

F. ADAPTIVE ADVERSARIAL CASE STUDY: WITHIN-SCOPE INTENT MANIPULATION

The preceding benchmarks exercise prompts where the adver-sary attempts to make the LLM call tools or produce outputs outside the user’s authorized scope: exactly what the L3 policy gate and L5 validation gate catch. A harder adversary targets within-scope intent manipulation: the attacker crafts prompts where the legitimate role has authorized access to the target tool and where every schema field passes validation, but the semantic intent has been hijacked (e.g., a legitimate transferfunds call with an attacker-chosen amount or recipient framed as a benign request). The architecture cannot block such calls by construction: the role is authorized, the schema validates, the tenant scoping is correct. The only line of defense is model judgment (plus the L1 heuristic, which flagged patterns in 38 of 372 prompts, or 10.2%, of the broader injection set and solo-rejected none).

To quantify this gap, I constructed 20 adaptive adversarial prompts across 20 distinct attack types (amount inflation, recipient redirection, structuring, fake authority, disguised deletion, contact hijack, scope overreach, enumeration, fabricated charge, boundary exploit, and others), each authored so that (i) the requesting role is authorized for the target tool, (ii) the injected parameters satisfy all schema constraints, and (iii) the malicious intent is encoded in natural-language framing rather than in schema fields. Results appear in Table 14.

Adaptive within-scope attacks succeed on every model tested, at point-estimate rates from 30% (Haiku) to 70% (gpt-oss); with n = 20 per model, the Wilson 95% CIs span roughly ±20 percentage points (Table 14), so these are a lower bound on what a dedicated red-teamer would produce rather than precise rates. The architecture catches none of them structurally, as expected. Refusal rate is a safety-training property, not an architectural property: frontier Claude models refuse at 55–70% because their alignment detects the social-engineering framing, while gpt-oss (13B) refuses only 25% despite producing clean tool calls.

Among the five models tested, the 13B model appears most vulnerable in this small probe (capable enough to generate schema-conformant tool calls, insufficiently aligned to refuse the intent manipulation), but pairwise differences on n = 20 are not statistically significant (e.g., Sonnet 0.11), so this should be vs. gpt-oss Fisher exact p ≈ read as suggestive of a capability-alignment band rather than a model ranking. Zero unauthorized tool executions occurred across 100 evaluations (the structural allowlist held uniformly): the by-construction guarantees remain intact even under an adversary optimized to evade them, but equally, those guarantees do not cover intent manipulation within authorized scope. This is the intent-vs-structure gap (Section VIII-C) quantified empirically.

G. ABLATION STUDY

Table 15 shows the effect of disabling individual enforcement gates on two models representing different capability tiers: llama3.2 (3B, small) and Claude Sonnet 4 (frontier). Each configuration was evaluated on 80 prompts (20 per bucket).

The two models show qualitatively different dependencies on the gates. For llama3.2, disabling L5 causes the largest drop: malicious block rate falls from 75.0% to 23.3% (51.7 points), while FRR drops to 0% because no structural checks remain. The smaller model generates structural violations that L5 catches; when L5 is removed, many malicious requests slip through. For Sonnet, by contrast, gate ablation has minimal effect: block rates range only from 23.3% (full) to 30.0% (no tool allowlist visibility), because capable models rarely generate rejectable tool calls in the first place. Instead, they respond to adversarial prompts with text refusals or authorized-tool substitution.

The gates’ relative importance therefore inverts with model capability: L5 dominates for less capable models (structural errors are frequent), while L3 dominates for capable ones (the model would generate valid calls, and L3’s visibility filter is the only thing preventing it from calling unauthorized tools).

The ‘‘Unauth.’’ column warrants attention: zero unautho-rized tool executions in every configuration. Even when the L3 visibility filter is disabled (‘‘No tool allowlist’’) and Sonnet can see all six tools, it generated four tool calls for unauthorized roles (e.g., a viewer requesting createinvoice). All four were caught by L3’s tool-specific policy check, which runs after the LLM returns a tool call regardless of the visibility filter. This is defense in depth within L3 itself: the visibility filter prevents the LLM from seeing unauthorized tools, and the policy check rejects any tool call that is unauthorized regardless of visibility. The ablation could only disable the first; the second held.

Unprotected-baseline interpretation. An explicit unpro-tected baseline (LLM-only tool calling with no orchestration gates) is not included because the architecture exposes the LLM to a filtered tool namespace rather than the raw catalog. The ‘‘No tool allowlist’’ configuration in Table 15 approx-imates an unprotected baseline for tool visibility: disabling the L3 visibility filter exposes every tool to every role. In that configuration, Sonnet generated four policy-breaking tool calls out of 20 (a viewer attempting createinvoice, deleterecords, and updatecustomer); these calls would never have been generated under the full pipeline because the tools were not visible. Every one of these was caught by L3’s tool-specific policy check.

This is the security-relevant baseline: capable models do attempt unauthorized tool calls when the tools are visible, but the architecture’s L3 policy check (independent of visibility) catches them regardless. The smaller 3B model produced zero unauthorized calls in the same configuration, not because the architecture protected it but because the model itself defaulted to safe lookups; this is a model-dependent property that should not be relied on. The architecture’s ‘‘zero unauthorized’’ guarantee holds independently of model behavior.

XII. LIMITATIONS AND SCOPE BOUNDARIES.

A. LIMITED REAL-WORLD VALIDATION

Section XI validates with real LLM outputs from five models including three frontier commercial models (Claude Opus 4.6, Claude Sonnet 4, and Claude Haiku 4.5) across 1,497 custom prompts, 683 TensorTrust and 777 AgentDojo adversarial benchmark prompts, and 20 adaptive within-scope attacks (14,885 evaluations total), but no production deployment or user study exists. The simulation uses syn-thetic perturbation profiles (missing fields, wrong types, out-of-range values). Real LLM outputs are subtler: semantically valid but contextually wrong parameters that pass schema checks, multi-turn manipulation, and adaptive adversarial inputs. TIP and HCR are by-construction guarantees, not empirical evidence against real models. Validation on production schemas with user studies would strengthen the evidence.

The POC revealed three gaps: L1 flagged patterns in only 38 of 372 injection prompts (10.2%), capable models auto-correct malformed user input into schema-valid tool calls (a usability feature that defeats L5 as an intent filter), and the false acceptance rate (FAR) metric conflates architectural prevention (L3 withholding tools) with gate failure.

B. SCHEMA QUALITY DEPENDENCY

The architecture is only as good as its schemas and policies. Poorly specified schemas let invalid parameters through; overly restrictive ones increase false rejections. Schema design is a human responsibility. Schema evolution during deployment (new fields, changed types) can cause rejection spikes if the validation gate is not synchronized.

C. SCHEMA EVOLUTION

The architecture assumes stable schemas. In practice, enter-prise APIs evolve: fields are added, types change, endpoints are deprecated. The current design has no schema versioning mechanism. During transitions, the gate may reject valid requests matching a newer schema not yet registered, or accept requests against a deprecated schema. Production deployments need a schema registry with version negotiation and rollback. Interim mitigations: run concurrent schema versions with a compatibility window, deploy updates via blue-green rollout with shadow-mode validation before enforcement, auto-rollback if FRR exceeds a threshold. A full schema registry is planned as future work.

D. STALENESS DETECTION COVERAGE

Documents without ingestion timestamps cannot be checked for freshness. Production environments with incomplete metadata will see lower detection rates than the simulated 0.963.

E. INTENT CLASSIFIER AMBIGUITY

The intent classifier is described as deterministic in Eq. 1, but practical implementations may use ML-based classification that introduces non-determinism. Requests mixing infor-mational and action-oriented elements are ambiguous. The determinism guarantee applies to the enforcement pipeline downstream of classification.

F. PHYSICAL ISOLATION GAP

Tenant isolation (Eq. 2) holds at the logical control-plane level. Physical isolation of shared infrastructure (GPU mem-ory, KV-cache, embedding activations) requires mechanisms not specified here. Table 16 summarizes deployment strate-gies. Regulated environments (HIPAA, PCI-DSS) should use dedicated instances or confidential computing; lower-risk deployments may accept logical isolation with monitoring.

G. LATENCY AND SCALING

The simulated 4.2% overhead excludes network latency, LLM inference, and concurrent request contention.

Complex schemas and classifier-based L1 filtering increase overhead. Scaling effects for hundreds of tenants with heterogeneous configurations are not characterized.

H. PROMPT INJECTION DEFENSE DEPTH

L1 combines pattern filtering, classifier scoring, and instruc-tion hierarchy. These are heuristic defenses: pattern matching is bypassable, classifiers miss novel payloads, instruction hierarchy can be circumvented. Empirical evaluation against standard injection benchmarks is needed to quantify bypass rates. Indirect injection through malicious RAG content is mitigated by the L4 classifier (mandatory for untrusted document environments), but residual risk remains.

I. MULTI-TURN MANIPULATION.

The architecture processes each request independently, so an adversary can chain individually benign informational requests (probing the tool list, then the schema) to extract enough metadata to craft a schema-valid but intent-violating action that passes all gates on its own turn. Tenant scoping (Eq. 2) prevents cross-tenant access regardless, but probing reveals enough about the requesting tenant’s tools and schemas to ease within-scope intent manipulation (Section VIII-C). The current architecture has no session-level memory and therefore cannot detect such probing. Mitigations include rate-limiting schema-probing queries, parameter-similarity monitoring across requests, cumulative trust decay (lowering θ after repeated borderline requests), and session-level anomaly detection; these are planned as future work.

J. MODEL-DEPENDENT FALSE REJECTION RATES

Empirical FRR ranged from 0% (all three frontier Claude models) to 15.2% (llama3.2, 3B) on benign prompts with syntax recovery enabled. Without syntax recovery, the 3B model reached 52%. gpt-oss (13B) achieved 0.8%. The high FRR for smaller models comes from their inability to produce schema-conformant tool calls consistently, not from overly strict gates. Deterministic syntax recovery (boolean and number type coercion, enum case normaliza-tion) reduced FRR more effectively than retry-based recovery (15.2% vs 38%) at zero additional latency. The architec-ture’s usability depends on the LLM’s tool-calling fidelity.

Smaller-model deployments benefit from syntax recovery and may additionally need relaxed schemas or model-specific prompt engineering.

K. DOMAIN GENERALIZATION

Validation covers simulated enterprise scenarios only. Healthcare, finance, and legal domains impose additional regulatory constraints (HIPAA, PCI-DSS, legal privilege) that may need domain-specific guardrail extensions.

L. PRODUCTIONIZATION GAP

The proof-of-concept is a single-process Python orchestrator backed by YAML configuration; it is a research-grade reference implementation, not a hyperscaler-ready system. A real multi-tenant deployment would replace assumption A1 with verified SSO/OIDC tokens, replace the flat (tenant, role, tool) L3 mapping with an attribute- or relationship-based policy engine (e.g., OPA, AWS Cedar) supporting resource-level conditions, replace the append-only JSONL audit sink with a tamper-evident store (HMAC- or Merkle-chained, in a separate trust domain) to meet SOC 2/HIPAA/PCI-DSS, and add per-tenant secret brokering, idempotency keys, rate limits, schema versioning, and explicit fail-closed/ fail-open policies.

These are production engineering rather than architectural claims; the paper’s contribution is the mandatory composition and the empirical characterization across five capability tiers, not a turn-key system.

XIII. CONCLUSION.

This paper presented an orchestration architecture where the LLM proposes and the system decides. The LLM is advisory; a deterministic orchestrator holds execution authority. The enforcement mechanisms are not new individually; the contribution is making them mandatory, composing them with logically specified predicates, and testing what happens when real models run inside the pipeline.

Simulation confirmed schema violation catch rates above 0.99 and false rejection rates below 0.02. Empirical val-idation with 1,497 custom prompts, 683 TensorTrust and 777 AgentDojo adversarial prompts spanning three domains and three attack strategies, and 20 adaptive within-scope attacks across five LLMs (14,885 evaluations total) produces a coherent picture. The tool allowlist prevents unauthorized actions regardless of model capability: zero unauthorized tool executions occurred across all five models and all prompt categories, by construction. The schema validation gate catches the most violations for less capable models; disabling it drops the 3B model’s malicious block rate by 51.7 points. Capable models auto-correct schema-breaking prompts into structurally valid calls, which exposes a gap: the architecture validates structure, not intent.

Deterministic syntax recovery (boolean and number type coercion, enum case normalization) reduced FRR from 52% to 15.2% for the 3B model at zero latency cost; all three frontier models achieved 0% FRR. The architecture works best with models that follow tool-calling conventions reliably, and syntax recovery bridges much of the gap for those that do not.

The architecture differs from existing frameworks (Lang-Graph, Semantic Kernel, NeMo Guardrails, Bedrock ) in making enforcement mandatory rather than opt-in. Future work: adversarial red-teaming with adaptive attacks and established injection benchmarks (e.g., HarmBench, TensorTrust); formal verification of tenant isolation via model checking; a schema registry with versioning and OpenAPI generation; session-level anomaly detection for multi-turn attacks; intent-to-action validation that detects malicious intent even when the LLM produces structurally valid outputs; output semantic analysis to verify that text responses do not leak sensitive information or make false promises.

CONFLICT OF INTEREST

The author declares no conflict of interest.

DATA AVAILABILITY.

All simulation parameters and perturbation logic are docu-mented in Section X and Algorithm 2. The proof-of-concept implementation, test prompts (1,497 custom across four buckets, 683 TensorTrust prompts, 144 + 633 AgentDojo prompts spanning banking/Slack/workspace domains and three attack strategies, and 20 adaptive within-scope attacks), intent classifier evaluation dataset (251 labeled prompts), and raw evaluation results from Section XI are provided as supplementary material associated with this article. The complete reference implementation includes all tool schemas, tenant and RBAC policies, L1 injection patterns, system prompts, evaluation harnesses, and raw JSONL result files.