Embedded Agents vs Custom-Built AI Agents

Security teams now inherit two agent populations that arrived through different doors. One ships inside the SaaS platforms your business already runs. The other gets built by engineers on frameworks and hyperscaler runtimes. This guide covers what actually separates them and, more usefully, what does not.

The embedded vs custom AI agents question usually gets framed as a build-or-buy decision about speed, cost, and how much control your engineers want. That framing is fine for a product roadmap. It is close to useless for a security program, because both kinds of agent create the same failure mode. An agent holds credentials. It calls tools. It acts on behalf of a user whose real permissions may not match the credentials the agent is carrying. That mismatch is where privilege escalation, data exfiltration, and machine insider risk live.

The provenance of the agent does not change that mechanism. It only changes where the agent hides. Embedded agents hide in platform admin consoles that each speak their own dialect. Custom agents hide in Git repos, internal clusters, and personal developer tooling. Both grow weekly, and neither shows up cleanly in your existing identity governance or SaaS logs. Agents already move roughly 16 times more data than the humans they work alongside, and studies put about 90 percent of them in an over-permissioned state. Provenance is a footnote next to numbers like that.

Both categories automate work with a language model at the core. What differs is who builds them, where they run, and how their identity resolves.

Embedded and native agents

Embedded agents are prebuilt inside SaaS platforms and configured through no-code or low-code interfaces. Think Microsoft Copilot and Copilot Studio agents, Salesforce Agentforce, ServiceNow Now Assist, Glean assistants, and orchestration in tools like n8n. They live next to the data they act on, which is exactly why business teams love them and exactly why they concentrate risk. When an embedded agent is built in maker mode, it uses its creator's credentials on every invocation. A user with no access to the underlying CRM can invoke that agent and pull the records anyway. The agent did nothing unusual. Your identity layer was bypassed by design.

Custom-built and framework agents

Custom agents are constructed by engineers on frameworks such as LangChain, LlamaIndex, or CrewAI, or on hyperscaler runtimes like Amazon Bedrock and Google Vertex. Each carries an explicit identity, usually a service account or an OAuth client, and reaches its tools through MCP servers and direct APIs. Full control is the selling point and the liability in one. Every custom agent becomes your responsibility for identity, secret rotation, and observability. When these agents chain calls across systems, or a supervisor agent forwards its full context to a sub-agent, the blast radius compounds at each step.

Embedded agents live in platform admin consoles. Native tools can list them, but each platform exposes a different view and none of them reconcile across tenants or against each other. Assessments routinely surface hundreds or thousands of agents that were stood up before any security review, simply because the workflow to create one is a few clicks for a non-technical user. Discovery here means connecting to each platform's native API and adding browser-level telemetry to catch the shadow AI usage that never touched an admin console at all.

Custom agents hide in a different place. They live in source control, in internal Kubernetes clusters, and in individual developers' editors and MCP configurations. A single engineer can deploy a custom agent wired to production data over lunch, and nothing in your SaaS console will ever show it. Discovery here means runtime instrumentation on the agent platforms plus an inventory of MCP servers across both sanctioned and unsanctioned deployments.

The two paths converge on the same output: one inventory listing every agent, its owner, the tools it can reach, and its effective access. The Salesloft Drift campaign tracked as UNC6395, which reached roughly 700 organizations through a single abused set of connected credentials, is the argument for why that convergence cannot wait. The compromised identity was non-human, it was connected, and most victims had no single place to see what it could touch.

Governance works the same way for both populations: discover every agent, resolve its effective access, and hold that reality against policy. For embedded agents, that means understanding where each platform's guardrails end, because Copilot, Agentforce, and Now Assist each expose different admin controls and none of them show authority across the wider SaaS fabric. For custom agents, it means a source of truth for service accounts, MCP server inventory, secret rotation, and runtime observability across every framework in play.

Enforcement is where the platforms diverge. Runtime enforcement, blocking or altering an agent action while it happens, is available today for Claude and Microsoft Copilot. Obsidian delivers this as a decision engine the platform calls, an "Intel Inside" model rather than an inline gateway sitting in the request path, so the platform stays fast and keeps its native behavior. For Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Amazon Bedrock, Google Vertex, and n8n, the capability today is discover and govern: full inventory, effective-access mapping, and policy findings, with runtime enforcement on the roadmap rather than in production. Naming that split honestly matters, because assuming enforcement you do not have is its own control gap.

Effective access is what an agent can actually do inside a connected application once every entitlement, group, and inherited credential resolves. Theoretical configuration is what a policy file or a vendor's settings page says the agent should be able to do. Most tools show you the second and call it the first. They are not the same thing, and the gap between them is where incidents start.

The useful question is never which platform an agent came from. It is: which service account is this agent really using, which tables and objects and actions can that account touch, who invoked it, and what data actually moved as a result. Correlating an agent's live activity to that effective access inside the third-party application, not to a config page that claims a "read-only" role while an admin's maker-mode credential sits wired into the connector, is what turns a pile of agents into something you can govern. Measure both agent types against that single standard and provenance stops being the deciding factor.

Start with inventory, because you cannot govern what you have not counted. Pull every agent, embedded and custom, with its owner, its tools, and its data reach into one view. Then resolve effective access for the agents that touch the most sensitive data first. Then apply deterministic guardrails to the highest-risk agents, beginning with the reliable offenders: maker-mode agents, orphaned agents whose creators have left, publicly reachable agents, and toxic credential combinations.

Sequence the enforcement layer to what is actually available. Turn on runtime enforcement where it exists today, on Claude and Microsoft Copilot, and plan a governed rollout for the rest as the capability reaches those platforms. The goal is not more dashboards. It is one control plane that produces its own evidence, cuts the fire drills, and treats agent security as an ongoing program rather than a one-time procurement decision.