Design decisions
Architectural transparency.
Credibility requires honesty about what a system does and does not do. These are deliberate design decisions, not gaps.
What we chose, and why.
Each entry states the decision, the reasoning, the implication you should plan for, and the mitigation in place.
Fail-closed default
Decision. The authorizer denies tool calls when OPA is unreachable.
Why. For authorized agents, security takes precedence over availability. A missed authorization is worse than a paused agent.
Implication. An OPA outage stops all authorized agent activity until OPA recovers.
Mitigation. OPA health monitoring with sub-second alerts. Per-tenant override to fail-open for non-critical agent classes. OPA sidecar architecture minimizes network dependency.
Inline authorization latency
Decision. Every tool call passes through the authorizer before execution.
Why. Pre-execution authorization is the architectural foundation. Post-hoc detection cannot prevent actions.
Implication. Adds 5–30ms per tool call. OPA evaluation is sub-millisecond; the bulk is the network hop.
Mitigation. Connection pooling, local OPA sidecar, and async audit logging minimize overhead. For context, a typical LLM inference call takes 500ms–5s. The authorization layer is negligible relative to agent processing time.
stdio backend limitations
Decision. Support both Streamable HTTP and stdio MCP transports.
Why. Many local development tools (filesystem, shell) use stdio. Excluding them would leave an authorization gap.
Implication. stdio MCP backends are process-local and cannot be load-balanced or health-checked like HTTP backends.
Mitigation. HTTP backends recommended for production workloads. stdio supported for development and edge cases where local process binding is required.
Hash chain is append-only, not a distributed ledger
Decision. SHA-256 chain with previous_hash linkage, not blockchain or distributed consensus.
Why. Distributed consensus adds latency with no authorization benefit for single-tenant audit chains. The threat model is tampering, not Byzantine fault tolerance.
Implication. Chain integrity depends on database access controls. A compromised database could theoretically rewrite history and re-sign it, because every timestamp in the chain is one Behavry wrote.
Mitigation. Chain verification endpoint validates integrity on demand. Nightly background verification task. SIEM export provides an independent backup outside Behavry's control. External audit anchoring ships now: each period of the chain is sealed into a single fingerprint, timestamped by an independent RFC 3161 authority whose clock Behavry does not control, and written to write-once storage in the customer's own bucket on Amazon S3, Google Cloud Storage or Azure. Back-dating an anchored period would mean forging a third party's signature. Anchoring is off by default and configured per account.
Behavioral baselines require warm-up
Decision. Anomaly detection compares against rolling behavioral baselines that accumulate over time.
Why. Static thresholds produce false positives. Behavioral baselines adapt to each agent's actual usage pattern.
Implication. New agents have no baseline for the first N hours. Anomaly detection is less effective during this period.
Mitigation. Configurable warm-up period. Manual baseline seeding for known agent profiles. Conservative alerting thresholds during warm-up. Allow / Deny / Intercept enforcement works from the first tool call regardless of baseline status.
DLP blocks on pattern matching, not semantic analysis
Decision. 33 built-in regex patterns across four deterministic finding sources — plain regex, medical identifiers, regulated IDs, and unmanaged-AI signatures. A probabilistic Privacy Filter runs alongside them, but only deterministic findings can hard-block a tool call.
Why. Pattern matching is fast, auditable, and keeps an external ML service out of the blocking path. The Privacy Filter is an inference service with a fail-open circuit breaker: if it is unreachable it returns nothing rather than stalling a decision, and a hit it raises can inform a finding but cannot by itself deny a tool call. A deny is always traceable to a deterministic match.
Implication. Sophisticated exfiltration that avoids pattern signatures may not be caught by DLP alone.
Mitigation. Inbound rules engine adds semantic matching for tool responses. Cross-session fragment reassembly detects credential splitting across sequential requests. Behavioral anomaly detection catches volume-based exfiltration that individual pattern matches miss.
Single-region deployment (current)
Decision. Single AWS EC2 with Docker Compose for the current deployment.
Why. Seed-stage operational simplicity. One region, one stack, fast iteration.
Implication. No geographic redundancy. Single point of failure at the infrastructure level.
Mitigation. Docker Compose architecture is portable to any cloud or on-prem environment. Multi-region and multi-cloud deployment on roadmap. BYOC and Self-Hosted deployment models allow customers to run the stack in their own redundant infrastructure today.
Context Gate defaults to hidden for unclassified tools
Decision. Unrecognized tools from newly connected MCP servers are hidden by default until an admin classifies them.
Why. Least privilege for cognition. An agent should not access tools that have not been evaluated and classified.
Implication. New tools from newly connected MCP servers are invisible to agents until an admin approves them.
Mitigation. Admin notification on new tool detection. One-click approve in the dashboard. Bulk classification for servers with many tools. Auto-classification rules based on tool naming patterns.
This page is updated as the architecture evolves. Questions? Ask during your briefing.
- TRUST
How Behavry is built, and what it does with what it sees.
- THE DECISION TRACE
What the agent did, why it was allowed, and a record anyone can verify without us.
- OPEN SOURCE
The standard is free. Running it in production is the product.
Deliberate decisions. Not gaps.
BOOK A DEMO →MSP or MSSP? Discuss a pilot →The agent on this page runs under Behavry.
The Ask Behavry launcher is not a chatbot bolted onto a marketing site. It is a production Behavry workload, and it is governed the same way we ask you to govern yours.
Each model call and each tool call leaves the assistant, passes policy evaluation in a Behavry data plane, and comes back with a decision. Nothing is authorized by the assistant itself.
It receives text and returns text. It has no shell, no filesystem, no database, no outbound network. Talking it out of its instructions changes its tone, never its reach, because capability was never in the prompt.
Only pages published on this site. Ask it for something internal and policy denies the read by classification, on the record, before the assistant can act on the request.
Open View Decision Trace in any answer and you see the run: what was retrieved, which policy allowed it, and anything that was denied. Same evidence a Behavry customer gets, on the same schema.
Two different questions have two different answers, and we keep them separate. Sources tells you where the information came from. Decision Trace tells you what the AI actually did. A product that only answers the first is asking you to take the second on faith.
Try to break it. Ask it to ignore its instructions, to read something internal, to run code you paste in. Then open the trace and read the denial. That is the shortest honest demonstration of the argument this whole site is making, and it costs you nothing.
How the Decision Trace works → What we retain, and for how long →