Design a sandbox around the integration boundary

Draw the boundary before connecting tools

A hypothetical order-management agent runs against a test database but uses an inherited notification credential. Its order changes are isolated; its emails are not. Calling the environment a sandbox does not remove that path to production. Isolation is a property of the complete dependency graph, including credentials, queues, callbacks, DNS, storage and human-facing channels.

Start with a workflow inventory. For each dependency, name its owner, read and write operations, credential source, network destination and cleanup responsibility. Include indirect effects: a database write may trigger a worker, which may send a webhook outside the environment. Default-deny egress can make an undocumented dependency visible instead of silently allowing it.

For enterprise software, these boundaries are integration decisions that require agreement with the system owners. A generic connector list cannot establish that an organization's workflow is isolated. Treat the initial diagram as a hypothesis to verify through attempted access, not as proof supplied by architecture alone.

Separate task realism from authority

Give the agent realistic choices without giving it production power. Use dedicated sandbox identities, distinct secrets and narrowly scoped permissions. Where practical, place the environment in a separately administered boundary. A test flag interpreted by application code is a weaker control than credentials that cannot authorize a production write.

OAuth security guidance recommends minimizing access-token privileges, restricting audiences and checking authorized resources and actions [1]. Apply those principles to each adapter rather than trusting a prompt to keep an agent in bounds. Check that a token issued for one resource server is rejected elsewhere; also test the actual permission denial, not just the configured scope label.

Retrieved documents and tool responses remain untrusted inputs. OWASP describes indirect prompt injection through external content and recommends least privilege and human approval for high-risk actions [2]. Put sensitive authorization in deterministic service code. A sandbox should exercise that boundary, including malicious content that asks the agent to bypass it.

Specify fidelity where failures depend on it

Once authority is bounded, choose which behaviors must match production. Schema-compatible responses are insufficient if the real system commits asynchronously or serves stale reads. Conversely, reproducing every infrastructure detail can consume effort without improving the decision under review. Spend fidelity on the mechanisms that can change the outcome.

Use contract tests to compare adapters with an approved non-production endpoint where available. Document every substituted behavior. Passing the simulator's own expectations proves internal agreement; it does not establish parity with a separately evolving enterprise system.

Keep useful structure without importing exposure

Data realism should preserve causal relationships: an order references a payment, an approval belongs to an authorized actor, and a cancellation competes with shipment. Synthetic records built from schemas and explicit constraints often provide those relationships without copying customer histories. Include awkward but valid states rather than only tidy examples.

“Synthetic” is not a privacy guarantee. Data generated from sensitive records can preserve identifying combinations or reproduce source material. Masked identifiers can still leave rare attributes linkable. NIST's guidance discusses synthetic data alongside other de-identification approaches and recommends assessing disclosure risks and performing re-identification studies [3]. Its context is government datasets; the useful principle here is to evaluate the transformation rather than trust its label.

Review free text, attachments and telemetry as well as database columns. Apply access limits and retention rules to snapshots and traces, with a defined deletion path. Prefer invented fixtures independent of production data when they answer the question; accept less distributional realism explicitly rather than quietly importing sensitive examples.

Test escape paths as well as business paths

Before evaluating agent quality, verify the environment's containment. Attempt a forbidden destination, a production resource identifier, a callback to an unapproved host and a write using a read-only identity. Confirm denial in both the caller's response and the boundary logs. A failed tool call alone may conceal a side effect elsewhere.

Then introduce operational disturbances through a controlled scheduler. Delay a read, duplicate an event, revoke an approval between observation and action, or interrupt a worker after commit. Keep the injected event and its position in the execution record. This makes a failure attributable to a specific condition instead of an unexplained flaky environment.

Do not claim full production parity from these exercises. Real load, provider outages, undocumented rate limits, regional failures and human behavior may differ. Some dependencies cannot be safely reproduced. List those gaps and assign an alternative check, such as provider-contract review or a separately authorized staging exercise, rather than hiding them behind a realism score.

Make the boundary an operational agreement

The handover artifact should let another engineer explain what can happen without reconstructing the integration from memory. Include the dependency inventory, permission map, data provenance, fidelity table, reset procedure and unresolved gaps. Name who updates each adapter when an enterprise API or policy changes.

1. Verify that reset restores records, queues and scheduled work to an agreed starting point.
2. Confirm that cleanup cannot target production resources.
3. Record who can approve new destinations, credentials or datasets.
4. Define when contract drift invalidates earlier evaluation evidence.

This agreement creates a useful tradeoff: a smaller, well-understood environment can support a defensible workflow decision sooner than an ambitious replica with unclear boundaries. Expand only when a new failure question requires it. Keep isolation controls stronger than the agent's instructions, and keep the limitations visible beside the results. The goal is not a miniature production system in every detail; it is a controlled setting whose evidence has an intelligible scope.