Autonomous AI agents handle real operations on real infrastructure, often without a human in the loop on individual decisions. The system has to be designed so that what it does, who can change it, and what it has access to are all explicit, auditable, and bounded.
This page describes how we approach security architecture, deployment models, and compliance posture for every engagement we take on — and the additional protections we add for regulated industries, government, and security-sensitive deployments.
Security Architecture
→ Identity-bounded agents. Every agent's behavior is defined by an identity file (CLAUDE.md) that specifies what it can do, what it cannot do, and when it must escalate to a human. Agents do not interpret intent — they execute against documented rules.
→ Prompt injection defense. External inputs (data feeds, retrieved documents, user-provided content) are treated as untrusted by default. Agents do not execute instructions found inside data they were asked to read.
→ Escalation boundaries. All system-modifying actions, financial actions, and decisions outside an agent's defined authority require human approval. No silent auto-execution outside the documented escalation tier.
→ Input validation. Data feeds are pre-digested into version-controlled markdown snapshots before agents read them. This decouples decision-making from live data sources and creates a reviewable audit point.
→ Audit trails. Every autonomous decision and every escalation produces an audit-trail entry. End-of-period reviews cross-reference decisions against thresholds and outcomes.
→ Documented incident response. When something goes wrong — a misfired job, an unexpected output, a vulnerability — the response is documented, the architecture is updated, and the lesson is encoded into future deployments.
Deployment Models
We support deployment in any environment that meets the agent's operational requirements. The architecture is portable across:
→ Client cloud infrastructure. AWS, Google Cloud, Azure, or any cloud provider the client already operates in. Agents run inside the client's account, under the client's IAM, with no BNB persistent access.
→ On-premise deployment. Agents run on client-controlled physical or virtual servers. Suitable for organizations with data residency requirements or restricted cloud policies.
→ Private cloud deployment. Single-tenant cloud environments with isolated networking. Common for healthcare, finance, and government engagements requiring tenant isolation.
→ Isolated network deployment. Agents operate in network-segmented environments with restricted external access. Inputs and outputs flow through controlled channels rather than open internet.
IP & Data Ownership
Every engagement we take on is built on the principle that the client owns what we build for them. Specifically:
→ Client owns the infrastructure. Agents run on the client's own servers, cloud accounts, or designated environments. We do not host, own, or persistently access client systems after handoff.
→ Client owns the identity files. The CLAUDE.md identity files that define each agent's behavior are client IP. Clients can modify, replicate, or take them to other vendors at any time.
→ Client owns the data. All inputs, outputs, audit trails, and memory files generated by the agents reside in client infrastructure. BNB does not retain client data.
→ Client owns the deliverables. Architecture documents, configuration files, deployment scripts, and operational runbooks are transferred to the client at handoff.
Regulatory-Aware Posture
For regulated industries, government, and security-sensitive engagements, our methodology incorporates additional considerations from the architecture phase forward:
→ Compliance-aware design. Agent identity files are written to reflect the specific compliance requirements of the deployment context — healthcare, financial services, government records, or regulated cross-border data handling.
→ Audit-ready operations. Every decision generates a reviewable trail. Compliance officers and auditors can trace any autonomous action back to the rules in the identity file and the inputs that triggered it.
→ Data residency support. Deployments can be constrained to specific geographic regions or jurisdictions when regulatory or contractual requirements demand it.
→ Phased delivery with security gates. Engagements with regulated buyers proceed through documented phases — discovery, architecture, pilot, expansion, handoff — with explicit security and compliance review at each gate.
→ Documented vulnerability response. We've caught security issues in our own architecture and documented the patches. The same approach extends to client deployments — vulnerabilities are reported, fixed, and documented, never hidden.
What Stays The Same Across Every Engagement
Whether the deployment is a $5,000 single-agent system or a multi-phase enterprise engagement:
→ Identity files define and constrain agent behavior
→ External inputs are treated as untrusted by default
→ System-modifying actions require human approval
→ Audit trails are generated for every autonomous decision
→ The client owns the infrastructure, the agent logic, and the deliverables