When a vendor tells you an AI agent “runs inside your infrastructure,” ask a follow-up: where do the agent’s credentials live, where does it write its logs, and who can pull the underlying data at 2am if something breaks? If any part of that answer involves the vendor’s own servers, the phrase is marketing, not architecture. Real infrastructure containment means the agent’s runtime, its credentials, and your data stay inside systems you already own — the vendor configures and governs the agent, but never hosts it, holds a copy of your data, or sits in the path between the agent and your systems.
That distinction sounds abstract until the agent has write access. Read access that leaks is a privacy problem. Write access that leaks, or gets hijacked, is an incident — invoices approved, records altered, emails sent, all from an identity you can’t fully trace back to a person or a policy. The infrastructure question stops being a compliance checkbox the moment an agent can actually do something.
The vendor-hosted default creates a shadow copy of your business
Most AI agent platforms are built the way most SaaS is built: the agent runs on the vendor’s cloud, connects to your systems through API keys or OAuth tokens, and routes your data through the vendor’s servers to do the actual work — embeddings, orchestration, model calls, caching. Even when that data is encrypted in transit and at rest, the vendor now holds a working copy of your CRM records, your financial data, your customer PII, sitting in an environment you don’t control and often can’t fully audit.
If the vendor gets breached, you’re breached, on their timeline and their disclosure schedule. If the vendor gets acquired, subpoenaed, or quietly changes what it does with aggregate data, your customer records are part of that story whether you agreed to it or not. And because the agent’s reasoning and action logs live inside the vendor’s boundary, reconstructing exactly what it did — and why — means filing a support ticket and waiting, not running a query.
This is the part most demos skip. A pilot running against sandbox data doesn’t surface where the real records travel. Production does.
Containment means the vendor configures the system without sitting inside it
The alternative isn’t “trust us more” — it’s a different architecture. The agent’s identity is a scoped credential issued from your own IAM, not a vendor-managed key standing in for “the agent” across every system it touches. The orchestration layer — the logic coordinating tool calls, approvals, and multi-step actions — runs inside your cloud account or VPC, not the vendor’s. The audit log is a table in a database you own and can query without asking anyone’s permission.
This is where WiseKeel’s deployments differ from a typical vendor engagement: we design and configure the identity scoping, the orchestration layer, and the audit logging, but all of it deploys into your infrastructure. We don’t host your data, we don’t retain a copy of it, and we don’t pool it with any other customer’s. Our job is closer to an electrician wiring a panel than a utility company selling you power — we build the system, then we’re not standing inside it every time it runs.
That matters most for the governance layer specifically. An approval gate that decides whether an agent can issue a refund, update a contract, or send an external email is only as trustworthy as the environment enforcing it. If that policy engine lives on a vendor’s servers, you’re trusting their uptime, their access controls, and their incident response for a decision that touches your money or your customers. If it lives in your infrastructure, that trust boundary doesn’t extend past your own team.
If you want a concrete look at what this would take for your own stack, book a diagnostic call — it’s a working session on your actual systems, not a sales pitch dressed as one.
The model call is the one boundary this doesn’t erase
Containment has an honest limit: if the agent uses a hosted foundation model, the prompt itself — the piece with the actual customer data in it — leaves your boundary to reach that model provider. Running everything on-premises with an open-weight model avoids this, but at a real cost in capability and maintenance most mid-size companies aren’t set up to absorb. What you can control is what leaves and how much: minimizing what’s included in each call, redacting what doesn’t need to be there, and being clear-eyed with your team about which single hop is unavoidable given the model you’ve chosen.
Infrastructure containment also doesn’t fix pre-existing IAM hygiene. If your cloud environment already has over-broad roles or credentials nobody’s rotated in two years, deploying an agent inside that environment inherits those problems — it doesn’t repair them. And during the deployment phase itself, someone has to have enough access to build the thing; the honest answer is that setup requires trust too, just scoped, time-boxed, and removable once the system is live, not standing and permanent.
The question to sit with
Ask your current or prospective AI vendor, specifically, where your data sits while their agent is running — not “is it encrypted,” but which account, whose IAM, whose logs. If the honest answer is “somewhere in our cloud,” you’ve already answered the bigger question: whether you’re deploying an agent, or handing a piece of your business to someone else’s infrastructure.