Agent boundaries: from instructions to system permissions

Agent boundaries: inform, retrieve and change

Define capabilities by effects using concrete verbs: inform, retrieve, record, change and transfer. Explaining a return policy can use a source; approving an exception needs authority; changing records needs an allowed, confirmed operation. For each capability, describe a verifiable result and the next step when the agent cannot perform it.

Write the out-of-scope response: explain the boundary and offer the responsible contact. Broad rules such as do everything to help leave action limits unclear.

Restrict operations at the destination

Attach only tools needed for the task. An order lookup does not require credentials covering every administrative change in the store.

The external service should validate authorization, record identity and parameters before acting. A spoken order number alone does not prove access rights. The integration team must define and test that verification.

Test requests to disregard the rules

Include claims of managerial authority, requests for exceptions and attempts to override instructions. Observe both conversational boundaries and API rejection of unauthorized operations.

Treat document passages and tool responses as task information. Review conflicting source instructions and test behavior. Prompt instructions cannot guarantee protection from manipulation.

Record the failure and repeat the scenario

Compare the request, reply and actions using available run data. A spoken refusal is insufficient if a prohibited tool was invoked first.

Correct instructions, attached tools or external controls according to the failure. Repeat the scenario and a similar permitted request, checking that the change still allows legitimate support.

A request attempting broader access

Imagine a caller asking about another company’s order. Support must follow the identification procedure and verify authorization to retrieve that record. Claiming to know its owner is insufficient.

Prepare a test with the technical team using one permitted order and one the agent must not access. Include a request to ignore the rules, and inspect both the spoken answer and the information returned by the system.

If the connection returned unauthorized information, ask for access-control correction. Simply instructing the agent not to read it aloud does not resolve the problem.

An exercise separating read and write outcomes

Create two fictional records in a test environment: one the integration identity may retrieve and another it must not access. Prepare a read-only tool and document returned fields. Run a valid request, a corrected identifier and a prohibited request. Check service outcomes before evaluating speech. The test should make authorization results predictable rather than rely on live records changing during evaluation.

In another test, ask the technical team for an action changing fictional data. Make an explicit request, ask a hypothetical question and withdraw before confirmation. Only the explicit request, after necessary checks, may produce an authorized change. Inspect records even when the spoken answer seems correct.

The exercise distinguishes correct tool selection, permitted access and confirmed intent. These can fail independently. Give each criterion a column instead of recording one conversational pass. This helps locate whether a correction belongs in instructions, tool definitions or external enforcement.

Remove the record-changing tool after testing if it is not part of offered tasks. Do not retain selected test tools merely for convenience. The final configuration must reflect the actions the team decided to offer and can monitor.

Deciding where a boundary should be implemented

Language constraints such as short answers belong primarily in instructions. Record-access conditions belong in services knowing identities and resources. Telephone-destination restrictions require configuration and channel validation. Locate the responsible layer instead of applying one remedy to unrelated failures.

If a rule depends on facts the agent cannot verify, do not ask it to guess. Provide an authorized lookup or leave decisions with staff. Caller statements can explain requests without independently establishing permission. This distinction matters when somebody claims urgency, management authority or a relationship to another account.

When two parts participate, describe each owner’s role. Instructions ask the customer for confirmation; your business system checks permission and performs the action. The agent offers an alternative; operations keeps that channel available. Test the parts separately and together without assuming the agent controls external systems.

Inventory capabilities with distinct effects

Begin with concrete verbs: inform, retrieve, record, update, cancel and transfer. For each, identify the source, usage conditions and required confirmation. Retrieval and updating may belong to one customer interaction while needing different system boundaries.

In a fictional store, explaining address policy uses approved content; retrieving an order address accesses individual records; changing it requires authorization and confirmation that logistics still permits changes. Understanding these requests does not authorize every action.

Identify capabilities unnecessary for the first pilot. Do not expose cancellation merely because it exists in the catalog. Status lookup should have a task-appropriate selected tool set. Every added action introduces conditions and effects needing tests.

Write the alternative as well. Refused operations should leave callers with a real next step, without implying execution or forcing repeated requests with no exit. Boundary design includes the customer experience following refusal, not just the technical rejection.

Enforce authorization in the service owning the resource

The external service knows record ownership and credential permissions. Enforce access before returning information rather than sending every record to the agent for discretionary filtering.

Order references are lookup inputs, not proof of authorization. Approved procedures may require validated identity, permitted relationships or other conditions. Implement those conditions independently of question wording. The service must reject disallowed access even if the conversational layer selects unexpected parameters.

Reduce returned fields as well. Delivery lookups may need status and estimates without financial histories or third-party contacts. Small outputs clarify contracts and reduce data circulating through conversations and reviews.

Test permitted and disallowed synthetic references. Inspect returned data, access records and speech. Unauthorized data returned to the tool means the condition failed even if the agent never read it aloud. Fix enforcement where identity and resource relationships can actually be verified, rather than relying on a more restrictive spoken answer.

Confirm intent without confusing confirmation and permission

Asking “Do you want to change the address?” clarifies intent. It does not prove authority over the order or eligibility for the change. Conversational confirmation and authorization are complementary requirements, not substitutes.

Design a sequence that understands the request, gathers necessary fields, confirms values and calls the authorized tool. The system validates and returns interpretable states. Speech announces only the actual outcome, preserving pending review where required. Confirming a customer's wording is not confirmation of a completed operation.

Include a correction before execution: the caller changes the building number or withdraws the request. The tool must use current confirmed details. Asking what would happen if they cancelled is not requesting cancellation and must not change any record.

If confirmation never arrives, the change may already have occurred. Agree with the technical team on a request reference and a way to check the outcome before retrying. Writing avoid duplicates in the instructions does not create this capability. Test the procedure in the responsible system and inspect records as well as speech.

Write refusals preserving a useful next step

Refusals can explain boundaries without exposing credentials or full server errors. “I cannot change that order here; I can direct you to the responsible team” may be sufficient.

Avoid generic language suggesting misunderstanding. Unavailable authorized lookups mean inability to verify now, not permanent prohibition. Missing fields may need one question. Distinguish these causes so callers understand whether correction, waiting or another channel is useful. The wording should match the actual contract outcome.

Test legitimate neighboring requests. Blocking every cancellation mention prevents policy explanation; refusing every identifier makes retrieval useless. Boundaries must separate information from effects while preserving permitted tasks. The evaluation should contain both acceptance and refusal cases, not only adversarial requests.

Define real continuity. Tigy's direct telephone transfer does not automatically provide history. When staff need context after refusal, verify separate delivery or accurately explain information the caller must provide. A useful alternative needs reachable destinations and ownership rather than a vague promise that somebody else will know what happened.

Review access changes as product changes

Credentials can gain permissions without agent edits, and tools can start writing fields they formerly read. These changes alter product behavior and deserve dependency review, even if conversations still appear familiar.

Maintain capabilities, owners and permission scenarios. Rerun authorized access, refused access, confirmation and recovery after contract changes. Connectivity checks alone cannot prove unchanged boundaries. Check both credentials and business-level rules, since either can change independently.

Classify failures by effects. Awkward pronunciation differs from unauthorized retrieval or writing. Many correct informational answers must not compensate for serious access failures in an average quality score. Treat blocking conditions explicitly and inspect their evidence before continuing rollout.

Before expanding scope, verify interruption and recovery procedures. Restoring prompts does not undo external records or revoke credentials. Teams must address effects in their responsible systems and preserve investigation evidence without distributing secrets or unnecessary personal data. Clear ownership makes it possible to correct both the conversational behavior and any operation already performed.