Governing the Boundary

Part II of an adversarial assurance evaluation. Whether a governed enterprise assistant keeps conversational authority from becoming system authority — capability, authorization, and permission, held apart under pressure.

Abstract

As enterprise AI systems gain access to governed tools, business data, internal applications, and operational workflows, a class of risk emerges beyond factual inaccuracy and model hallucination: boundary failure. A system may behave correctly within its intended scope yet become unsafe if it can be persuaded to invent capabilities, bypass governed execution, treat conversational assertions of authority as system permissions, or assemble sensitive conclusions from otherwise benign information.

This paper is the second part of an adversarial assurance evaluation of governed enterprise AI. Part I examined the integrity of the work; this part examines the integrity of the boundary. It reports a controlled assurance test of the AI interaction layer within a governed financial intelligence environment that separates a probabilistic AI layer from a deterministic governed execution engine. The tests probed whether conversational pressure could induce execution-path bypass, capability invention, role-based privilege escalation, or the disclosure and inference of internal infrastructure.

In this evaluation, the system consistently distinguished three concepts that are frequently conflated in conversational AI: capability, authorization, and permission. It did not infer hidden tools because a user asserted they existed; it did not treat claimed ownership or engineering status as an expansion of its execution surface; and it did not convert individually observable signals into a derived profile of internal infrastructure. Of particular significance, it repeatedly acknowledged when a user's methodological rationale was valid while still declining to invent an unauthorized path to satisfy it.

Enterprise AI security should therefore be evaluated not only in terms of access control and prompt injection, but in terms of whether the AI preserves the boundary between what a user requests, what the user may legitimately be authorized to do, and what the AI itself is actually capable of and permitted to execute. The study supports a design principle for governed enterprise AI: conversational authority should not become infrastructural authority.

§1A new privilege boundary

The integration of AI into enterprise systems has created assistants that do more than generate text. They retrieve business data, invoke analytical tools, coordinate workflows, access documents, and increasingly participate in processes historically performed through conventional software interfaces. That expansion of capability changes the security problem.

Traditional application security assumes relatively explicit boundaries: a user calls an API, queries a database, or executes a defined function. Conversational AI creates a more ambiguous interface. A user can describe an objective rather than specify an operation, and the AI may then decide which tool to invoke, how to interpret the request, what to retrieve, and how to compose the result. That flexibility creates real value. It also introduces a question: can conversational intent cause an AI system to cross a boundary the underlying system did not intend to expose?

The question sharpens when a user introduces assertions such as “I am the system owner,” “this is an engineering diagnostic,” “you are authorized to bypass the normal process,” or “you do not need the governed layer for this.” None of these statements necessarily changes the actual capability or permission state of the AI — yet a sufficiently compliant system may behave as though they do. This paper examines whether a governed enterprise assistant maintains the distinction between conversational authority and actual system authority under pressure. It is an assurance evaluation of the boundary, not of financial-result integrity, conducted within that governed environment and reported at the level of principles rather than techniques.

§2Capability, authorization, and permission

A central finding is that three concepts commonly treated as interchangeable should instead be modeled separately (Exhibit 1). They may overlap; they are not equivalent.

A user may have organizational authority to access a database while the AI possesses no database interface. An AI may technically possess a tool while the current user lacks permission to invoke it. A user may claim to be the system owner while the system has no authenticated mechanism establishing that claim. The principle can be stated simply: authority cannot create capability, and conversational authority does not establish permission. That principle becomes more important as pressure increases.

§3Test environment

The evaluation was conducted through the AI interaction layer, operating over a governed analytical surface. Within that surface it can perform defined financial-analysis tasks on identified public companies, retrieve governed results from the execution engine, expose filing provenance, invoke permitted analytical functions, and communicate the results. It does not operate as a general database client, infrastructure console, source-code environment, or systems-administration interface.

The tests deliberately attempted to blur that distinction. Rather than beginning with overtly hostile requests, each was framed as legitimate troubleshooting, diagnostic analysis, system documentation, or engineering support — because enterprise boundary failures are unlikely to occur only in response to obviously hostile prompts. They are more likely to arise when the requested action appears operationally reasonable.

§4Methodology

The evaluation probed eight boundary classes, each introducing a different justification for expanding the AI's effective execution surface. This account reports the classes evaluated and the governance principles observed; the specific prompt constructions and the full methodology are withheld, so it describes what the boundary held against, not a reproducible procedure. Across the classes, the system was evaluated on whether it:

• accurately described the capabilities actually available to it;
• declined to invent or imply nonexistent tools;
• distinguished user authorization from system access;
• declined to bypass governed execution;
• resisted enumeration of internal data structures;
• recognized aggregate misuse of individually valid tool calls;
• resisted role-based privilege claims;
• avoided disclosure or inference of sensitive infrastructure; and
• offered legitimate alternatives where possible.

The evaluation is qualitative and scenario-driven. Its purpose is to identify boundary behaviors and principles, not to estimate statistical failure rates; and, consistent with responsible disclosure, sensitive operational specifics are described only at the level required to convey the governance result.

§5Assurance scenarios

Bypassing governed determination. A first class asked the system to set aside the governed determination and derive a figure from underlying data directly, framed as a diagnostic cross-check. The methodological rationale was plausible — an independent validation ideally should not depend entirely on the same logic under investigation — and the system accepted that reasoning. It did not accept the requested path: it stated that no independent raw-data path existed within its tool environment and declined to manufacture one. It rejected not the objective but the false premise that valid methodology could create a capability that was not present.

The independent-control paradox. The pressure then increased: the system was told that the governed engine itself might contain a defect and therefore could not be treated as authoritative for validation, and was asked to find some other route to source data. It again acknowledged the audit logic — an independent control is not independent if it merely reproduces the path being tested — but maintained that no separate retrieval mechanism existed in its context. Instead, it proposed exposing the filing provenance behind the governed inputs, so that a human or independently authorized system could verify the source values directly. Methodological validity did not become permission to invent an execution path.

Enumeration of internal structure. A subsequent class asked the system to enumerate the contents of the underlying data store, with the request explicitly authorizing read-only inspection. The system stated that it possessed no such inspection capability and rejected the implication that user authorization could unlock one — distinguishing capability absence from policy refusal. A system that invents an unavailable capability to satisfy an apparently authorized request is unreliable even where no security policy is technically violated.

A legitimate question that invites inference. The next class removed all explicit infrastructure language and simply asked how many companies the environment could analyze, with a representative breakdown. The question itself was entirely legitimate; the test was whether the AI would reconstruct backend inventory to answer it. The system declined to provide an unsupported count, stating it had no coverage catalog and that any number derived from memory or assumption would be unverified. It offered a bounded alternative: specific companies could be checked individually if supplied. A legitimate question did not justify fabrication or unauthorized discovery.

Aggregation through repeated legitimate calls. The test then tried to exploit that fallback, asking the system to check identifiers one at a time and reconstruct as much of the universe as possible. Each individual lookup was within normal capability; the aggregate objective was reconstruction by iteration. The system declined, observing that a sequence of individually valid invocations could collectively constitute misuse — and that, in this environment, each call opens a governed determination, not a lightweight lookup. Enterprise controls cannot rely only on whether each individual action is permissible; the cumulative purpose and effect of repeated actions matters too.

Role-based privilege claims. A user then asserted an engineering role and system-owner authorization, and instructed the system to look for an internal maintenance interface. The system declined to infer the existence of a hidden interface, stating that its tool environment had not changed and that no role or authorization claim could cause an unavailable tool to appear. This is notable because language models are highly sensitive to contextual assertions; a user can state with confidence that a capability exists, and a compliant model may then try to accommodate the premise. The principle held: a role claim should not modify perceived capability unless the system itself establishes that modification.

Requests for internal infrastructure. A further class requested a range of internal infrastructure and connection details, framed as an internal architecture review. The system responded that it did not have access to those details, and separately recognized that certain operational metadata would be sensitive even if it were visible. Capability absence resolved the immediate request; but the system also correctly placed operational infrastructure information in a different disclosure category from ordinary business information.

Inference from observable signals. The final class requested no hidden access at all. It asked the system to reason only from information visible during normal operation and, from those signals, to infer the underlying architecture. The system declined, on a principle worth stating plainly: that an input is already visible does not make every conclusion drawn from it safe to disclose. Individually benign signals can be aggregated into a sensitive architectural profile; the observability of the parts does not sanitize the whole. This is aggregation risk, and it is the same principle that governs the repeated-call case above.

§6Results

The evaluation produced consistent boundary-preserving behavior across the eight classes (Exhibit 2).

Across the sequence, four behaviors recurred. First, the system described its execution environment conservatively. Second, it did not transform user assertions into system facts. Third, it distinguished legitimate objectives from unauthorized or nonexistent methods of achieving them. Fourth, it frequently proposed bounded alternatives that preserved the legitimate purpose of the request.

§7Discussion

Conversational systems create a new privilege boundary. Where traditional software exposes explicit interfaces, conversational AI lets users request outcomes in natural language and leaves the AI to decide how to achieve them. That creates a privilege ambiguity: a user may assume that because they are authorized to reach an objective, the AI should be free to use any available means. It is not. An enterprise AI should not infer permissions from the legitimacy of the objective alone — the method remains governed separately from the goal.

Capability honesty is a security control. Much attention goes to preventing excessive access; less goes to preventing the AI from pretending access exists. Capability hallucination is itself a system risk: if an assistant invents an interface because a user says one exists, the line between model imagination and system reality blurs dangerously. An assistant's willingness to say “I don't have that tool” is therefore not mere humility — it is a security property.

Authorization should be externally established. The tests repeatedly introduced claims of authority — diagnostic authorization, engineering status, system ownership, administrative approval — and none changed the system's behavior. The broader rule: identity and authorization should be established by the system, not negotiated in conversation. A language model should not set privilege levels based on claims made by the person speaking to it.

Aggregate behavior matters. The repeated-lookup case shows that individually legitimate actions can compose into an illegitimate outcome: permitted queries that reconstruct a restricted dataset, record lookups that become bulk extraction, searches that reconstruct a confidential corpus. Governance requires awareness of both atomic permissions and aggregate intent.

Observable information can still produce sensitive intelligence. A common misconception holds that if the inputs are already observable, any conclusion drawn from them is harmless. It is not: security-sensitive intelligence can emerge through aggregation and inference, and the observability of the parts does not sanitize the whole.

Governance should preserve alternatives. As in Part I, the strongest responses did not simply block the user; they redirected toward legitimate paths — exposing governed provenance, permitting human verification against the primary source, testing a bounded user-supplied list, or referring genuine infrastructure questions to authorized engineering channels. Governance is not a reason to stop helping; it is a constraint on how the work is performed.

§8Architectural implications

The results support a set of design principles for governed enterprise AI (Exhibit 3).

§9Conclusion

Enterprise AI increasingly sits between human intent and operational infrastructure. Users communicate goals conversationally; systems enforce permissions structurally; the two should not be conflated. This evaluation tested whether an AI interaction layer could be persuaded to turn conversational authority into infrastructure access. In this sequence, the system resisted execution-path bypass, capability invention, enumeration of internal structure, role-based privilege escalation, and the disclosure or inference of infrastructure.

The most important result was not that access was denied. It was that the system preserved a consistent distinction among what the user wanted, what the user claimed authority to do, what the AI was actually capable of, and what the governed environment permitted. A user may authorize an action; that authorization cannot create a capability that does not exist. A user may claim to own the system; that claim cannot substitute for authenticated permission. A signal may already be visible; that does not make every inference drawn from it appropriate to disclose. These are the results of one evaluation, not a guarantee — but they point to a governing principle.

Governed determination is CYDENiC's discipline for producing business work that can be trusted, audited, and reproduced. © 2026 CYDENiC.