Chrysent Sandbox
Design-partner previewPolicy-controlled sandbox access and isolation capabilities are available to design partners.Control where agentic workloads can connect, which credentials they can use, and which repository and provider actions policy allows — inside customer-owned infrastructure.
The problem this solves
Agents need access to repositories, providers, and tools to do useful work, but broad access can expose credentials, data, and destinations beyond the task you approved. Teams need explicit controls that bound that access to the approved work.
Chrysent Sandbox makes repository, network, credential, runtime, provider, and tool controls explicit. It gives security and platform teams a policy-controlled environment for agentic work while keeping software and retained product data in customer-controlled infrastructure. Customer-configured external model providers receive provider-bound request data under the customer's provider agreement.
What changes when you adopt Sandbox
Policy-controlled access
Chrysent Sandbox provides policy-controlled sandbox access with repository-specific rules and separate read/GET and write/POST permissions.
Allowed destinations and bounded credentials
TLS/SSL inspection enforces allowed destinations, and credential rewriting exposes only fake or scoped credentials inside the sandbox.
Runtime and network isolation
Kata container runtime isolation and Cilium network-policy isolation bound sandbox execution and network access.
Controlled provider and tool use
Controlled LLM-provider access and server-side tool execution keep provider and tool use within policy.
How Sandbox operates
- 01
Define repository access
Set repository-specific access rules and separate read/GET from write/POST permissions to match the work approved for each repository.
- 02
Isolate sandbox execution
Kata container runtime isolation bounds the workload, while Cilium network-policy isolation bounds its network access.
- 03
Control destinations and credentials
TLS/SSL inspection enforces allowed destinations. Credential rewriting ensures only fake or scoped credentials are exposed inside the sandbox.
- 04
Govern providers and tools
Policy controls LLM-provider access and server-side tool execution so model and tool use stay within the approved boundary.
Component map
- Repository policyRepository-specific access rules with separate read/GET and write/POST permissions.
- Destination and credential controlsTLS/SSL inspection for allowed destinations and credential rewriting for fake or scoped credentials.
- Isolation controlsKata container runtime isolation and Cilium network-policy isolation.
- Provider and tool controlsControlled LLM-provider access and server-side tool execution.
For the full platform architecture, see /platform.
Who uses it and how
AI platform engineering
Scenario: You need to give an agent repository and provider access without exposing every destination or credential in the environment.
Gain: Repository-specific permissions, allowed destinations, and fake or scoped credentials inside a policy-controlled sandbox.
CISO / Security
Scenario: You need explicit runtime and network boundaries around agentic workloads and their server-side tools.
Gain: Kata and Cilium isolation combined with controlled LLM-provider access and server-side tool execution.
Government / Regulated
Scenario: You need agentic evaluation to respect data sovereignty, residency, and repository-specific access requirements.
Gain: Self-hosted controls in customer-owned or customer-controlled infrastructure, with retained product data kept there and provider-bound requests governed by the customer's provider agreement.
See the product surface
Product screenshots and a short demo walkthrough are available to design partners under NDA. Request access below to receive the latest captures and a recorded session.
Request access →Supported systems
Chrysent Sandbox integrates with the providers and frameworks below. Each entry shows the current support status. Documentation for the full integration list is coming soon.
- Kata container runtimeTech Preview
- Cilium network policyTech Preview
- Customer-approved LLM providersTech Preview
- Policy-controlled server-side toolsTech Preview
Where it runs and how data is handled
Chrysent sells self-hosted software only. Software and retained product data remain in customer-owned or customer-controlled infrastructure. Customer-configured external model providers receive provider-bound request data under the customer's provider agreement. This model supports data sovereignty and residency requirements. Data handling and retention are described on the Data handling & deployment page. Security architecture, encryption, and incident response are documented on Security & trust.
Benchmark and evaluation methodology
The first public benchmark study is in preparation. Until it ships, design partners can request the evaluation methodology and a private run report under NDA via the contact form.
Other Chrysent products
Common questions
Where does Chrysent Sandbox run?
Chrysent Sandbox is self-hosted in customer-owned or customer-controlled infrastructure, and retained product data remains there. Customer-configured external model providers receive provider-bound request data under your provider agreement. This model supports data sovereignty and residency requirements.
How are repository permissions separated?
Repository-specific access rules distinguish read/GET permissions from write/POST permissions, so each repository exposes only the operations allowed by policy.
Which credentials are visible inside the sandbox?
Credential rewriting exposes only fake or scoped credentials inside the sandbox.
How are external destinations controlled?
TLS/SSL inspection enforces allowed destinations, and controlled LLM-provider access applies policy to provider connections.