AI systems, and autonomous agents especially, open an attack surface that traditional application security was not built for. A normal web app does only what its code permits. A model reads input at runtime, decides what to do, and an agent can then act on that decision through a terminal, a file system, or your APIs. That turns untrusted text into a control path: a prompt injection becomes a real action. We implement the technical controls that secure these systems and help you meet your obligations under HIPAA, SOC 2, and GDPR. We are an engineering team, not a certification body, so we build systems that stand up to your auditors and your threat model, and we stay on to operate them. Bitontree has built production AI since 2019 from Ahmedabad with US-overlap hours, including a nightly medication-adherence voice system and SOAP-note automation under exactly these constraints.
Securing an AI system is not a single product you switch on, it is a layer of controls that constrains what a model and its tools can actually do. We design that layer so no single failure exposes the whole system, then operate it in production rather than hand over a diagram. Each control closes a specific failure mode the OWASP Top 10 for LLM Applications warns about.
Every agent starts with the minimum access its task needs and nothing more. Credentials are issued per environment, so a staging token can never reach production, and capabilities widen only after the system proves itself on reversible work. If an agent is injected, the attacker inherits only that narrow scope.
Code and tool calls run inside an isolated sandbox, never on a host with reach into your network. We match isolation to risk: Docker for baseline separation, gVisor to shrink the syscall surface for less-trusted code, and Firecracker microVMs for genuinely untrusted input. The file system is scratch and egress is filtered.
We put a governed tool layer between the model and your systems, usually an MCP server, so the agent calls named, permissioned tools instead of raw SQL or open HTTP. The server validates arguments, enforces scope, and logs every call. This is the choke point for input validation, approval gates, and egress rules.
Credentials never live in prompts, code, config, or logs. They sit in a managed store like HashiCorp Vault or AWS Secrets Manager, scoped to the narrowest access a service needs and rotated on a schedule. The agent calls a tool that uses the secret, so the value itself never enters the prompt or the transcript.
We assume injection eventually succeeds and design so a success still cannot do damage. Untrusted content is delimited and treated as data, not commands, input and output are filtered, and tool arguments are validated rather than passed raw. An injected instruction can only attempt actions you already scoped.
For every consequential step we capture what the agent did, why, on what inputs, and who approved it. Records are append-only and timestamped as tamper-evident evidence, the same kind a SOC 2 or HIPAA audit samples, with secrets and raw sensitive data kept out. We pair this with periodic access reviews.
AI and agent systems fail in ways a normal web app does not, and most map to the OWASP Top 10 for LLM Applications. The danger compounds when a model that reads untrusted content can also act on it. These are the risks we design against from the start.
An injected chatbot says something wrong; an injected agent runs a command. The instruction can arrive directly from a user or hide in content the agent ingests later, a web page, email, ticket, or document. The model cannot tell trusted instructions from attacker text, so any input it reads is a path to action once it can call a tool.
Broad tool access lets an agent read data it should never touch and forward it out. An injected instruction tells it to look up a record and post it to a webhook, an email, or a fetched URL. Without scoped credentials and egress allow-lists, one instruction moves data out the door. This is sensitive information disclosure meeting excessive agency.
Keys sitting in files, prompts, environment dumps, or logs that an autonomous process can read are a breach waiting to happen. An agent that reads its own config can read the API key in it, and a verbose agent can write that key into a log an attacker later mines. The fix is a managed store, fetched at call time, never in a prompt or transcript.
Sends, deletes, payments, and writes to systems of record with no human checkpoint are the textbook case of excessive agency. The gap between what an agent can do and what it should do unsupervised is where the damage lives. We route irreversible or externally visible actions through an approval gate and keep scoped credentials so a confident mistake stays small.
Model output passed unchecked into a shell, a database query, or another system turns a wrong answer into an injection of its own. The model is just a text generator, so its output is untrusted until something validates it. We treat every response as data to be screened before it touches code, not a command to run as written.
When an agent keeps memory or pulls from a knowledge base, hostile content it reads can quietly lodge there and steer later runs. A one-off exception absorbed as a standing rule, or a poisoned document in a retrieval set, gets applied confidently until a human catches it. We review what an agent writes and ground retrieval in approved sources.
Security comes from stacked controls, not a single guardrail. We bound data access, tool policy, secrets, human approval, and audit evidence so the blast radius stays small.
We have built and run production AI since 2019 from Ahmedabad with US-overlap delivery hours, including a nightly medication-adherence voice system and SOAP-note automation under real compliance constraints. The operating model is what sets the work apart: we embed senior engineers, harden the system, and stay on to run it. An AI system with nobody accountable for its security is a liability, so we do not hand over a threat model at go-live and walk away.
We are an engineering team, not a certification body, and we never claim to hold SOC 2 or HIPAA certification on your behalf. We implement and document the technical controls those frameworks require, so when your auditor or your customer's security team looks, the controls are real and the evidence is there.
No single layer is trusted to hold. Scoped credentials, sandboxing, governed tools, egress control, and approval gates stack so that even a clean prompt injection runs into a wall before it becomes a damaging action. We design for the failure we expect rather than the demo that happens to work.
Security advice from people who have never shipped the thing tends to miss the unglamorous parts. Our engineers have put AI into environments where failure has consequences, so a review from us comes with the controls already implemented and operated, not a checklist handed back over the wall.
We run AI in regulated settings today, including a nightly voice system that calls patients about medication and automation that drafts clinical SOAP notes. That experience shows up where it counts: secrets handling, audit trails, minimum-necessary data, and incident response that holds under a real audit.
Controls drift, keys need rotating, and new attacks change the picture after launch. We embed with your team to build the security layer and then keep running it: monitoring, re-running red-team evals, applying upgrades, and refreshing access reviews, so the boundary stays defensible instead of decaying.
For systems that touch PHI, we implement the HIPAA Security Rule technical safeguards and draw the model boundary so raw PHI stays out of prompts. We support BAAs, connect to Epic, Cerner, and Athenahealth over FHIR, and already run AI in healthcare today under these constraints. The covered-entity obligations stay with you.
Money movement and access to financial records demand hard checkpoints. We put human approval gates on anything that moves funds or writes to a system of record, scope credentials per environment, and keep tamper-evident audit trails so every consequential action is reconstructable for your auditors and your own incident response.
When an AI feature ships inside your product, a SOC 2 question from a prospect can stall the deal. We design and document the controls so they line up with the Trust Services Criteria, then embed with your engineering org and wire the security layer in behind the same release process you already trust.
Privileged documents and client confidentiality leave no room for a tool quietly forwarding data out. We ground agents in approved sources, lock egress to allow-listed destinations, and keep processing on infrastructure you control so sensitive material never crosses a boundary it should not.
Agents wired into a storefront touch customer data, orders, and payment flows, all attractive targets for an injected instruction. Governed tools turn those connections into named, logged calls, while approval gates and egress controls keep an automated job from leaking customer records or acting on a payment unsupervised.
High-volume document and exception work pulls in untrusted files from many senders, a natural carrier for indirect injection. We run processing in a sandbox with filtered egress, treat every uploaded document as data rather than instructions, and route writes to your TMS or ERP through approval and an audit log.
Start with a security readiness review. We assess your AI or agent system against this control set, sandboxing, least privilege, governed tools, secrets management, approval gates, egress control, and audit trails, then hand you a risk report with a prioritized remediation plan. The review stands alone: you walk away with a clear path either way.
We harden AI systems through a staged path from threat model to monitored production controls. Each step produces evidence, not just advice, so your team can launch with boundaries your security reviewers can understand.
We map the model boundary, data flows, untrusted inputs, tools, users, and irreversible actions before changing the system. The output is a risk map tied to OWASP LLM failure modes and your compliance obligations.
Model and data-flow mapping
Untrusted input inventory
Tool and action review
OWASP LLM risk mapping
Compliance requirement map
We design the controls that constrain the system: least-privilege access, sandbox boundaries, governed tools, egress rules, secrets handling, approval gates, and the audit evidence each control must produce.
Least-privilege design
Sandbox and egress plan
MCP tool contracts
Secrets and key policy
Approval gate map
We implement the controls inside your actual stack, not in a slide deck. That means policy-enforced tools, managed secrets, runtime isolation, structured logging, and review flows wired into the systems your AI already uses.
Governed tool layer
Managed secret integration
Runtime isolation
Policy validation
Review workflow wiring
We test the system with direct and indirect prompt injection, excessive-agency cases, data-exfiltration attempts, and failure-mode evals. Launch waits until the controls hold under the threats the system actually faces.
Prompt-injection tests
Exfiltration simulations
Excessive-agency checks
Audit-trail validation
Launch readiness report
After launch we keep the boundary alive: access reviews, key rotation, trace review, eval updates, alert tuning, and evidence collection for audits and customer security reviews.
Access reviews
Key rotation checks
Trace and alert review
Eval suite updates
Audit evidence collection
For systems that touch PHI, we implement the HIPAA Security Rule technical safeguards: unique identities and least-privilege scopes, TLS in transit with AES-256 at rest, tamper-evident audit logging, and minimum-necessary data handling. We support BAAs and align the architecture to the rule. The covered-entity obligations stay with you.
We design and document AI systems so their controls line up with the SOC 2 Trust Services Criteria and the relevant ISO 27001 Annex A controls: least-privilege access, sandboxing, secrets management, monitoring, and change control. The payoff is evidence your auditor can sample, not a control that lives only in a policy document.
When personal data cannot leave a region or your own infrastructure, we keep it there by design. Open-weight models in your environment or private in-region endpoints stop prompts crossing a border, and data-subject access, export, and deletion paths reach every store the agent wrote to. The same approach serves any contractual residency requirement.
A control that exists only in a slide deck fails the moment someone asks to see it work. We produce the access logs, audit trails, and architecture notes that show each safeguard is real and operating, so your audit team spends its time confirming evidence rather than scrambling to manufacture it.
Done right, a compromised AI system's reach stays small. Sandboxing, scoped egress, least privilege, and approval gates turn a successful injection into a contained event rather than an open-ended one, so the value of the system does not come bolted to an unbounded risk you cannot answer for later.
Append-only run traces and per-call logs let you answer what the system did, why, and on what inputs after the fact. That visibility is what makes an AI system reviewable, drives root-cause investigation during an incident, and produces the same evidence a SOC 2 or HIPAA audit asks to see.
A default deployment ships the model and its tools without the layer that constrains them. The difference is whether an injection ends at a wall or inside your systems.
| Default AI deployment | Secured with Bitontree | |
|---|---|---|
| Tool and data access | Broad, often unscoped | Least-privilege governed tools |
| Execution environment | Runs on the host | Sandboxed, egress-filtered |
| Irreversible actions | Run without a checkpoint | Route through approval gates |
| Secrets handling | Keys in config or env | Managed store, fetched at use |
| Audit and evidence | Whatever logging defaults to | Tamper-evident, queryable trail |
Talk to our engineers about the system you are shipping. You will get a straight read on where the risk is, the controls to put in place first, and what it takes to keep the boundary defensible after launch, whether you are securing a new agent or hardening an existing AI feature.
Bitontree built these systems and runs them in production today: agent pipelines that process invoices, nightly voice calls to patients, and automated lead handling for real clients.
AI-powered invoice processing for a Singapore-based logistics enterprise. OCR and ML automate data extraction, validate against business rules, and process invoices end-to-end across multiple formats and currencies.
An AI system decides what to do at runtime based on input, so untrusted text becomes a control path rather than just data.
A traditional app does only what its code allows, and a review can reason about every branch. An AI system reads input, chooses an action, and an agent can carry it out through a terminal, files, or APIs. A prompt injection can then trigger a real action, not just a wrong answer.
So defense is less about patching code and more about constraining what the model can do: scoped credentials, a governed tool layer, sandboxed execution, input and output filtering, and approval gates on irreversible actions. The OWASP Top 10 for LLM Applications catalogs the failure modes; the controls contain them.
It is the reference list of the most serious risks specific to systems built on large language models. For agents, four items matter most:
The rest, including supply chain and model denial of service, still apply, but those four define most of an agent's real-world blast radius.
We assume injection will eventually succeed and design so that a successful injection still cannot cause harm. No model is reliably immune to hostile text in its context, so we never rely on its judgment alone.
The result is defense in depth: even a clean injection hits a wall before it becomes a damaging action.
It happens when an agent with legitimate tool access is tricked into reading sensitive data and sending it somewhere it should not go.
A typical path: an indirect injection in a document or web page tells the agent to fetch a customer record, then post it to an attacker's webhook, attach it to an outbound email, or encode it into a URL it loads. The agent uses exactly the tools you gave it, just for the attacker's purpose.
We stop it with layers:
No single layer is trusted; the point is the data has nowhere to escape to.
No. Bitontree is an engineering team, not a certification body, and we do not claim to hold SOC 2, HIPAA, or any other certification on your behalf. We are honest about this because the alternative misleads you about who carries the obligation.
What we do is implement and document the technical controls those frameworks require: access control, encryption in transit and at rest, audit logging, data minimization, sandboxing, and secrets management.
The certification, the audit, and the attestation are yours to obtain and maintain. Our role is to make sure that when your auditor or your customer's security team looks, the controls are real and the evidence exists.
Yes. Where residency or regulatory rules demand it, we run models and agents locally or on private endpoints so personal and protected data never leaves your environment or its required region.
The same approach covers contractual residency requirements beyond GDPR, including data that must stay in one cloud region or never touch a third-party model API.
A Business Associate Agreement covers how a vendor handling PHI on your behalf will safeguard that data; it does not transfer your underlying HIPAA obligations to that vendor.
Under a BAA, the business associate commits to appropriate safeguards, limiting use and disclosure to what the contract permits, reporting breaches, and supporting your compliance, and the agreement makes those duties enforceable. We support BAAs for the systems we build and operate, and we implement the technical safeguards that make the commitments real: access control, encryption, audit logging, and minimum-necessary handling.
What stays yours is the role of covered entity or primary business associate:
A BAA is a control on the relationship, not a way to outsource responsibility. We make the engineering side defensible so your obligations are easier to meet.
We attack it the way a real adversary would, then gate the launch on whether it holds up. The agent must pass a defined suite of adversarial and behavioral checks before production, and the same suite runs again on every change.
What we probe:
Findings get a severity, a reproduction, and a concrete fix. The launch decision is whether the agent survives its own threat model, and we keep running the evals after launch because new attacks and tools change the picture.
We keep them out of the model's reach entirely and fetch them only at the moment of use. Credentials never sit in prompts, code, config files, environment dumps, or logs, because anything in the agent's context or transcript can leak through injection or verbose logging.
If an agent is compromised, the attacker inherits only that narrow, rotating scope.
It must capture what the agent did, why it decided to, and on what inputs, in a record that cannot be quietly altered after the fact.
For every consequential step:
Records are append-only and timestamped so they hold up as tamper-evident evidence, not logs anyone can edit. Two things matter beyond completeness: secrets and raw sensitive data stay out of the trail (an audit log an attacker can mine for credentials or PHI is itself a liability), and the trail is queryable so an incident becomes a root-cause investigation instead of guesswork. This is the same evidence a SOC 2 or HIPAA audit samples, so one trail serves both incident response and compliance.
Because it assumes the program's behavior is fixed by its code, and an agent's behavior is decided at runtime by a model reading input.
SAST, DAST, and dependency scanning still matter and we run them, but they look for known vulnerability classes in deterministic control flow: injection into a query, a missing auth check, an outdated package. They were not built for a system where instructions arrive as untrusted text and the model chooses which tool to call. None will flag that a support ticket can talk your agent into emailing a customer record outside the org, because at the code level nothing is broken; the agent uses its tools exactly as designed.
Securing an agent also needs threat modeling around the model boundary, red-team testing for prompt injection and excessive agency, scoped credentials, sandboxing, egress control, and approval gates. We layer the AI-specific controls on top of the appsec basics, not either one alone.
A readiness review looks at where untrusted input enters your system, what the model is allowed to decide, which tools and data it can reach, and who owns the security boundary after launch, then scores that setup against the control set and the OWASP LLM Top 10.
Concretely, we map the data flow and its risk, review tool and credential scope, assess the sandbox and hosting plan, and check it against least privilege, governed tools, secrets management, egress control, approval gates, and audit trails. We also map the obligations your data carries under HIPAA, SOC 2, or GDPR to the safeguards that satisfy them. The deliverable is a risk report and a prioritized remediation plan you can act on with us or hand to your own engineers. The review stands alone: you get a clear, honest plan whether or not you continue with Bitontree afterward.
Notes from securing autonomous agents and production AI in the real world: prompt-injection defense, scoped credentials and secrets, sandboxing and egress control, audit trails, and what it actually takes to meet a compliance obligation rather than claim one.
Connect with our team to harden AI and agent systems and meet the security and compliance obligations your data carries.
6+
Years Of Experience
40+
Skilled Professionals
105+
Projects Delivered
35+
Global Clientele Served
