Asyrx opens its enterprise AI agent sandbox program

Asyrx is opening a qualification-based enterprise AI agent sandbox program for organizations running agents against systems of record. Approved teams receive environment-scoped credentials, the documented Salesforce, Shopify and GitHub reference scenarios, Action Simulator access, and a structured evaluation plan built around their own action inventory.

There is no public free plan and no anonymous sandbox, and that is a deliberate design choice rather than a gate for its own sake. An action risk assessment is only meaningful against a real action inventory. A generic playground would produce scores nobody can act on, so each sandbox is provisioned around the actions a specific organization actually delegates to agents.

Why the program exists

Almost every enterprise conversation about agent risk arrives at the same impasse. The security team can describe the actions that worry them — bulk exports, refunds, permission grants, mass cancellations, repository deletions — but has no way to quantify them consistently, and no shared vocabulary for discussing them with the platform teams shipping the agents.

The sandbox turns that impasse into an experiment. Teams replay actions they have already seen, including the ones that caused incidents and the ones that were escalated unnecessarily, and compare the resulting Action Risk and Blast Radius Scores with the decisions their own reviewers made at the time. That comparison is the point: it tells an organization whether the scoring matches its risk appetite before anything touches production.

What a sandbox includes

Sandbox keys are environment-scoped (the asyrx_test_ prefix) and isolated from production assessment history, so teams can replay real actions without touching live records or contaminating live baselines.

• Scoped test credentials with rate limits and idempotency enabled
• The Salesforce flagship integration, plus Shopify and GitHub coverage
• Action Simulator access for constructing edge-case scenarios by hand
• Calibration of Action Risk and Blast Radius against your historical outcomes
• Reason codes and recommended controls on every assessment, for review workflows
• A published OpenAPI 3.1 contract and quickstart for the integration team

How an evaluation is structured

Evaluations follow the same shape regardless of industry, because the hard part is rarely integration. It is agreeing on which actions matter and what should happen at each risk band.

Most teams reach a defensible threshold configuration within a few weeks, and the artifact they keep is as valuable as the scoring itself: a written inventory of high-impact agent actions, with an agreed response for each risk band.

• Scope — list the agent actions that write to a system of record and rank them by consequence
• Replay — submit historical actions, including known incidents and known false escalations
• Compare — put the scores next to the decisions your reviewers actually made
• Tune — set thresholds and routing per action category, not one global cutoff
• Integrate — place the single assessment call between proposed action and execution

What high-impact action inventories usually look like

Across early evaluation conversations, the actions teams nominate as high impact cluster into a small number of families, and they repeat across industries. Bulk data movement is almost always first: exports, syncs and reports that leave a system of record with more data than a human would ever have requested by hand. Financial actions come next, usually refunds, credits, payouts or discount changes, where the exposure is easy to quantify and therefore easy to argue about.

The third family is access change — permission grants, role assignments, token creation, repository and branch settings — and it is consistently the one teams underestimate. A permission grant is cheap to execute, hard to notice, and expands what every future action can do. The fourth is destructive or irreversible operations: mass deletes, mass cancellations, schema or configuration changes. Reversibility, not volume, is what makes this family dangerous.

Naming these families early makes the rest of the evaluation faster, because thresholds and routing rules are agreed per family rather than argued action by action.

• Bulk data movement — exports, syncs and large reads that leave the system of record
• Financial actions — refunds, credits, payouts, pricing and discount changes
• Access change — permission grants, role assignments, credential and setting changes
• Destructive operations — mass deletes, mass cancellations, irreversible configuration changes

The artifact teams keep afterwards

The most durable output of a sandbox evaluation is rarely the integration. It is a written, agreed inventory of high-impact agent actions with a defined response at each risk band, owned jointly by the security team and the platform team that ships the agents.

That document survives model changes, framework migrations and vendor decisions. It is also the thing auditors and regulators ask for, because it demonstrates that consequential automation was reasoned about deliberately rather than discovered after an incident.

What the program does not do

Asyrx does not authorize, approve, deny, block or execute customer actions in a sandbox or in production. Every assessment is decision-support intelligence, and the enterprise's own systems and reviewers retain final authority. A sandbox cannot therefore break an agent pipeline, because it is never in the enforcement path.

The program also makes no claim about compliance certification. Asyrx publishes its security and compliance posture and its sub-processors, and evaluation teams are encouraged to read both during the technical review rather than take a summary on trust.

How evaluation data is handled

Replayed actions are described as structured metadata — action type, scope, exposure, destination and identifiers — rather than as copies of the underlying records, so evaluations rarely require moving sensitive content anywhere. Teams that need to keep specific fields out of scope can generalize or omit them and still get a usable assessment, at the cost of some confidence.

Where an evaluation does involve regulated data, the applicable terms, the published sub-processor list and the data processing addendum govern it, and technical reviewers are encouraged to read those documents during the review rather than at contract signature.

Requesting access

Enterprise sandbox and agent risk assessment requests are reviewed by the Asyrx team. Qualified organizations receive an architecture walkthrough and a concrete evaluation plan tied to their own action inventory — not a scripted demo.

Organizations embedding assessment into a product they sell, rather than using it internally, are reviewed through the OEM path instead, because the integration and commercial questions are different.