Deploy AI agents into existing systems, not another platform

Amazon Bedrock offers a checkbox that saves roughly 10% on inference. Choose a global cross-Region inference profile rather than a geographic one and, per AWS's own documentation, requests are "Routed worldwide" to "Any supported AWS commercial Region worldwide" — including "AWS Regions that are not manually enabled in your AWS account". One configuration line, one residency consequence. That is the argument in miniature: when you deploy AI agents into existing systems, decisions like that stay inside an estate you already govern. Buy an agent platform and they multiply, most of them made by someone else.

What it actually means to deploy AI agents into existing systems

The agent vs platform architecture split comes down to five things, none of them marketing. A deployed-in agent runs inside your trust boundary. It authenticates as a principal in your existing identity provider. It reads through the APIs your applications already expose, under the rights of whoever invoked it. It writes back to the system of record, not a shadow copy. Its activity lands in your SIEM.

A platform agent inverts all of it. Connectors pull copies of your records into the vendor's store, the vendor issues its own roles, the vendor holds the authoritative log of the agent's actions, and the answer is as fresh as the last sync job.

Published guidance now points the same way. In Managing the cyber risk of agentic AI (20 August 2026), the NCSC states that "All agents should be assigned their own unique identity in a class which differentiates them from human or individual systems", with "only the permissions it needs for the task being performed" and "credentials with the shortest possible lifetime". Both are cheaper to satisfy in an estate that already runs an identity provider, a secrets manager and a SOC — which is how our agent deployments are built.

The platform model duplicates a permission model you already run

This is where most agent integrations go wrong. Microsoft's identity platform draws the line precisely: a delegated permission means "The application isn't able to access anything the signed in user couldn't access", whereas an application permission such as Files.Read.All means the app "is able to read any file in the tenant" (Microsoft Learn, updated 25 June 2026).

Connectors overwhelmingly take the second route: tenant-wide permissions are provisioned once and survive any user's absence. The vendor then rebuilds your row-level security in its own retrieval layer, from its own copy of your group memberships. You now have two authorities on who can see what, and only one updates when someone changes team on a Tuesday.

That failure mode is measurable. GROUND (Pillai, arXiv, submitted 6 July 2026) found ungoverned systems "violate row-level security on many questions", and — the sharper result — that "A semantic-only condition with exact metric definitions but no access policy still leaks data". Definitions are not enforcement. Only the source system can enforce the source system's rules.

AI agent integration for CRM and ERP: APIs, connectors and MCP, honestly

The integration layer deserves a straight account. For AI agent integration across CRM and ERP estates there are three real options, each with a distinct security posture.

• Direct APIs. Most work, best fidelity. The vendor's own authorisation checks run on every call, rate limits included, and nothing is copied.
• Vendor connectors. Fastest to switch on, and the usual vehicle for the tenant-wide permission problem above. Read the scope list before the feature list.
• Model Context Protocol. Genuinely useful for standardising tool discovery, and worth adopting — provided you are clear about what it is not.

MCP is explicit about its own limits. The specification (revision 2026-07-28) states that "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD" build consent and authorisation flows themselves, and that "descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server" (modelcontextprotocol.io). It is a transport and discovery protocol, not an authorisation system — and treating it as one is where MCP security in the enterprise goes wrong.

The concrete case: CVE-2025-6514, an OS command injection in the mcp-remote npm package, carries a CVSS v3.1 base score of 9.6 (Critical), vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, affecting versions 0.0.5 to 0.1.15, published 9 July 2025 (GitHub Advisory Database; discovered by JFrog Security Research). The mechanism matters more than the score: a malicious MCP server returns a crafted authorization_endpoint URL and the client executes it. Trust flows the wrong way — from the server you connected to, into the machine you own.

The project's own security best practices document the rest of the class: confused deputy attacks on proxy servers with static client IDs, SSRF via discovery URLs pointing at cloud metadata endpoints, and token passthrough, where the rule is unambiguous — "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." None of this makes MCP unusable. It makes every MCP server a dependency to version-pin, egress-control and, where it touches production data, run first-party inside your boundary.

AI agent data residency and the sub-processor chain you inherit

Return to that Bedrock checkbox. AI agent data residency is decided by defaults, and defaults are set by whoever operates the runtime — which, on a platform, is not you.

Count the hops. A typical platform is your data, in the vendor's application, on the vendor's cloud account, calling a model provider, often with a separate observability service in the path. Under GDPR Article 28(2), "The processor shall not engage another processor without prior specific or general written authorisation of the controller", and Article 28(4) is blunt: "the initial processor shall remain fully liable to the controller." You sign for that chain whether or not you have enumerated it. Deploying in collapses it to your cloud account, your chosen region, one model endpoint whose terms you read.

Why retrieval-grounded agents beat prompt-only ones

A prompt-only agent knows what was written into its instructions at configuration time, plus whatever the last sync left in its index. It will answer about an order, a claim or a ticket fluently, with no idea whether the record changed an hour ago.

A retrieval-grounded agent queries the system of record at answer time and returns the record identifier alongside the answer, so a human can open it. Grounding pays on accuracy alone — Anthropic's contextual retrieval work (19 September 2024) cut top-20-chunk retrieval failure from 5.7% to 1.9%, a 67% reduction, combining contextual embeddings, BM25 and reranking. The stronger reason is auditability. An answer traceable to a record is one you can walk a regulator or an angry customer through. An answer synthesised from a stale index is a claim.

The GROUND results add the caveat: retrieval alone is insufficient without policy enforcement at query time. Grounding and permission inheritance are one decision seen from two angles — both require the agent to ask the real system, as a real principal, at the moment of the question.

The honest trade-offs of the deployed-in model

This approach is slower and less impressive to watch. Anyone claiming otherwise is selling.

• Slower to start. Network paths, service principals, change approval. Weeks, not an afternoon; a platform demo can be live before lunch.
• It needs access. Someone senior must grant it, and scoping it properly is real work no vendor can do for you.
• Harder to demo. No polished sandbox of synthetic data. A convincing proof needs a real or masked copy of your own records, which needs its own approval.
• You own the runtime. You patch it — on your schedule, not a vendor's release note.

The platform model is genuinely better in specific cases: the data is already SaaS-native and low sensitivity, there is no system of record to write back to, or the point is simply proving a use case exists. The NCSC's advice in Thinking carefully before adopting agentic AI (15 May 2026) — "deploy agentic AI incrementally, starting with tightly bounded pilots using clearly defined tasks" — applies to both architectures. It is cheaper to obey in one.

How to test a vendor's claim in a pilot

Every vendor says "your data stays in your systems". These six tests separate the ones who mean it, and all fit inside a two-week pilot.

• Revoke mid-session. Remove a test user's role in your identity provider while a conversation is open. Does the next request fail, or succeed until the nightly sync?
• Ask for something forbidden. Request a record the test user has no rights to. A deployed-in agent surfaces a 403 from the source system. An indexed agent often answers from its own copy.
• Change and re-ask. Edit a field in the CRM or ERP, then ask the same question 60 seconds later. Freshness is a property of the architecture, not the model.
• Pull the audit trail from your own SIEM, not the vendor console, and confirm the agent appears as a distinct identity.
• Demand the sub-processor list and inference region in writing, then verify them against the running configuration, not the deck.
• Enumerate the MCP servers. Which ones, pinned to which versions, running where, with what egress rules. A vendor who cannot answer in a day has not thought about it.

Our security questions to ask before signing covers the contractual side in more depth.

Braivex builds agents that run inside the systems you already operate, authenticate as principals in your identity provider, and are paid for on outcomes rather than seats. To put those six tests to a working agent against your own estate, get in touch and we will scope a pilot.