Chrysent Bastion

The problem this solves

An assistant with access to tools, local machines, remote systems, or MCP servers can take destructive actions before anyone notices. Existing security tooling was designed for human operators and does not model agent intent, scope, or policy.

You need a pre-tool-execution hook that evaluates every proposed tool call against policy before the harness executes it — with defaults that match the threats you actually face and a transparent decision trace when something is denied or requires human review.

Real incidents in 2024–2026 include coding agents running `rm -rf ~/`, wiping developer databases, dropping production-style data, and triggering `terraform destroy` against live environments. None of these were caught before irreversible action.

What changes when you adopt Bastion

• Pre-execution policy decisions

  Evaluate every proposed agent tool call before the harness executes it. Bastion returns allow, deny, or human-review decisions through its customizable policy engine and never executes tools.

• Policy-as-code with sane defaults

  Built-in protections for dangerous commands and protected paths. Extend with a policy DSL for organization-specific rules. Customer safety customization is bounded data — never executable code, never network or filesystem access from the rule itself.

• Transparent decision trace

  Every decision recorded with context — explainable to the agent when transparency helps, concealed when revealing policy would help an attacker. Rejected calls return stable codes such as category-scoped filesystem, container, Terraform, cloud, SQL, or source-control diagnostics.

• Audit-ready decision log

  Every proposed tool call, policy decision, and reported execution outcome is available to your SIEM or data warehouse. Bastion failures produce an explicit “unavailable” or “incomplete” result rather than “allow”; evidence records the release as a safety bypass if a pre-authorized fail-open is configured.

How Bastion operates

1. 01

   Configure Bastion as a pre-tool-execution hook

   Configure Bastion as a pre-tool-execution hook in your agent harness. It evaluates each proposed tool call against a customizable policy engine and reports whether the call is allowed, denied, or requires human review. Bastion does not execute tools.

2. 02

   Apply default policies

   Dangerous commands, protected paths, and high-risk operations are blocked out of the box. Each block has a reason and a stable diagnostic code.

3. 03

   Add organization-specific rules

   Write custom policies in the Chrysent DSL or import rules from your existing security tooling. Policies can be tested in dry-run mode before they are promoted to enforcement.

4. 04

   Trace and audit

   Every decision is logged with the rule that fired, the version set of Bastion and Gateway that participated, and the cryptographic chain position. Replay any blocked or allowed call to understand what happened and why.

Component map

• Bastion pre-tool hookConfigured in the agent harness to evaluate proposed tool calls and return allow, deny, or human-review decisions. Bastion never executes tools.
• Policy engineCustomizable DSL-driven rules with version control, a tester for dry runs, and explicit freshness behavior.
• Decision traceImmutable record of allow / deny / human-review decisions, with stable diagnostic codes and the cryptographic chain position.
• Gateway integrationRoutes Bastion decisions through the same control plane so the session ledger and the audit surface are unified.

For the full platform architecture, see /platform.

Who uses it and how

• CISO / Security

  Scenario: You want to allow agentic workflows without exposing the organization to undelimited risk.

  Gain: A boundary with policy-as-code, default protections, and a full decision trace for investigations.

• Engineering leadership

  Scenario: You are adopting coding agents and want to limit which files and commands they can touch.

  Gain: Protected paths, dangerous-command detection, and the ability to test policies before they run in production.

• Government / Regulated

  Scenario: Procurement and audit require evidence that agent actions are bounded and reviewable.

  Gain: A policy engine with explainable decisions, an immutable decision log, and export to your SIEM.

See the product surface

Supported systems

Chrysent Bastion integrates with the providers and frameworks below. Each entry shows the current support status. Documentation for the full integration list is coming soon.

• Model Context Protocol (MCP) serversGenerally available
• OpenAI function-calling agentsGenerally available
• Anthropic tool-use agentsGenerally available
• Custom agent frameworksRoadmap
• Local shell and filesystem toolsGenerally available
• Remote execution (SSH, kubectl, terraform)Tech 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

• Chrysent AI Gateway

  Private beta

  Chrysent AI Gateway provides centralized control over AI usage across multiple vendors and models.

• Chrysent Touchstone

  Private beta

  Chrysent Touchstone focuses on protecting AI systems from malicious or unsafe interactions.

Common questions

• What is the policy DSL?

  A small, version-controlled language for declaring tool-call rules. Policies can be tested in dry-run mode before they are promoted to enforcement. Customer safety customization is bounded data, not executable code.

• What happens when Bastion blocks an action?

  The agent receives a structured refusal with a stable diagnostic code and an optional explanation. The decision is recorded in the audit trace. Bastion never executes tools; when policy requires human review, it returns that outcome to the agent harness before execution.

• Does Bastion run in our environment?

  Yes. Bastion 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 does Bastion interact with Gateway?

  Decisions flow through Gateway so the session ledger and the audit surface are unified. The end-to-end interaction records the complete version set used across both components.