Native AI Agents Inside SaaS: The Hidden Attack Surface

Your Salesforce admin turned on Agentforce for lead routing last quarter. Marketing enabled Copilot Studio agents to summarize campaigns. A developer wired an internal assistant to three connectors to speed up debugging. None of it hit procurement. None of it triggered a security review. That is the shape of the problem: native AI agents ship inside the SaaS tools you already own, activated by feature flags and consent prompts that route around your onboarding controls.

These are not third-party integrations you can block at the identity provider. They are the SaaS application itself, now able to take multi-step actions on your data. The pain shows up as operations before it shows up in a threat model. Boards and audit committees are asking security teams a simple question: which AI agents exist across our estate, who owns them, and what can they touch? Most teams cannot answer any part of it. One enterprise assessment surfaced hundreds of Copilot agents nobody had catalogued. Another team found the count already in the thousands before any inventory process had started.

What Native AI Agents Actually Are

A native AI agent is an AI feature the vendor built directly into a SaaS platform, able to take autonomous actions using that platform's data, permissions, and connected tools. Microsoft Copilot Studio, Salesforce Agentforce, Amazon Bedrock agents, Google Vertex AI, ServiceNow Now Assist, Snowflake Cortex, and workflow builders like n8n all fit the pattern.

The distinction from an external AI service is the trust boundary. When you call an outside model through an API, it sits on the far side of a wall you control. A native agent lives inside the wall. It uses the same authentication, the same data paths, and the same audit logs (or the same gaps in them) as the platform hosting it. You are not adding a vendor. You are switching on latent capability inside a vendor you already trusted.

Native agents inherit trust because they authenticate with the same OAuth scopes, service accounts, and bearer tokens the SaaS application uses, and because most were built to run in maker mode, executing with the creator's credentials rather than the invoker's.

Here is the mechanism in plain terms. When a business user builds an agent in Copilot Studio or Agentforce, the platform binds that agent's connectors to the builder's identity. Every downstream user who invokes the agent, including users with far lower permissions, then acts at the builder's privilege level. If the builder was a Salesforce administrator, anyone who can talk to that agent now holds effective admin access to whatever the agent can reach. This is not a defect. It is how the platforms are designed. The consequence is that your IAM controls stop describing what a user can do. A user with no Salesforce license can invoke an agent that has one and pull restricted CRM records. The agent broke no rule. Your access model was simply routed around.

Maker Mode and the Credential Problem

Agents hold credentials in a few forms, and each one carries the same flaw: bearer token trust. Embedded maker credentials fix the agent to its creator. Delegated OAuth tokens ride in from the invoker. Hardcoded secrets sit in workflow configs. In all three cases the token does not verify who is holding it. Whoever presents it gets the authority.

The UNC6395 campaign that moved through Salesloft Drift and into connected Salesforce environments reached roughly 700 organizations by abusing exactly this assumption. Stolen connected-app tokens looked identical to legitimate integration traffic, so the activity blended in. An AI agent is, functionally, another bearer token holder acting with the full authority of whoever provisioned it. That makes it a machine insider: a non-human identity operating inside your trust boundary at machine speed.

What Data These Agents Can Actually Reach

A native agent can reach whatever the underlying user, service account, or connector was granted, and in most deployments that is far more than the task needs. Reported patterns put roughly 90 percent of AI agents over-permissioned relative to the work they actually do. Copilot Studio agents commonly touch the connected user's mailbox, Teams messages, and SharePoint sites. Agentforce agents inherit Salesforce object-level permissions. Bedrock agents run under an IAM role that often carries far more storage and downstream service access than the workflow requires.

This is where the real question lives, and where a vendor's configuration page will mislead you. The config screen shows theoretical configuration: the scopes an agent was assigned. It does not show effective access: which service account the agent authenticates as, which specific objects, tables, and actions that identity can reach in the third-party app, and which of those it exercised. Closing that gap means correlating the agent's runtime activity to its real reach inside the platform, not reading the setup wizard back to yourself.

Native agents cluster across three surfaces, each with its own trust model and its own blind spot.

Most enterprises are running agents on all three at once with no unified view across them. Each vendor console shows only the agents built in that vendor. None of them show which humans invoke which agents, and none show what an agent actually reached during a given run.

How to Tell If Your SaaS Tool Has Native Agents

Check three places. Look in the admin console for AI feature toggles labeled Copilot, Agent, Assistant, or Studio. Look at the connector or integration catalog. Look at any AI-branded feature the vendor launched in the last year and a half. If your vendor shipped an AI capability recently, assume it is agent-capable and check whether users have already built on it. Practical signals that an agent is live include new OAuth scopes appearing on service principals, rising API activity from platform-owned service accounts, and staff mentioning automations they built themselves.

Which Vendors Ship Them

The short answer is all of them. Every major enterprise SaaS platform now embeds agent capability directly: Microsoft, Salesforce, Amazon, Google, ServiceNow, Atlassian, and Snowflake among them. Independent workflow and search tools add another layer on top. The question for a security team is no longer whether native agents are present. It is how many, owned by whom, and reaching what.

Security teams cannot secure agents they cannot see, and no SaaS vendor offers inventory across platforms. That single gap is the biggest blocker to any agent security program.

Each platform ships its own admin console showing its own agents. None reveal agents built elsewhere. None map which humans invoke which agents. None show what data an agent actually touched during execution. Where native logs exist, they are siloed, noisy, and demand manual correlation across tenants before they mean anything. One CISO called the resulting work ghost chasing: reviewing theoretical risks that describe what could happen, with no evidence of what did. Another team said outright that they needed to model real permissions from observed behavior because static configuration was lying to them about actual access. That is the demand for runtime truth stated in the customer's own words.

Common Deployment Mistakes

The same patterns show up in assessment after assessment:

1. Turning on Copilot or Agentforce estate-wide with no inventory or ownership model, so agents get created faster than anyone can track.
2. Building in maker mode by default, so every invoker inherits the creator's credentials.
3. Granting org-wide or public visibility "temporarily," which then becomes permanent.
4. Leaving orphaned agents running after the creator's account is disabled, so the agent keeps executing with a dead user's access.
5. Treating native audit logs as the security control, when those logs never describe effective access or agent-to-agent chaining.

Can These Agents Be Manipulated

Yes, and the reliable method is not exotic. The confused deputy pattern turns an over-permissioned agent into a proxy: an attacker who cannot reach data directly asks an agent that can, and the agent has no way to check whether this invoker should trigger this action in this target app. Action chaining compounds it. An agent acts in Salesforce, passes context to a copilot, which calls into SharePoint, which surfaces a file back to the original user. No single step looks wrong. The chain moves data no one was ever cleared to see, and it does it at a speed no human review keeps up with. Public reporting suggests agents move roughly 16 times more data than human users in the same environments.

Knowing an agent exists is the easy 10 percent. The security question is what each agent can execute, on whose behalf, with what downstream reach, and whether any of that matches policy. That is effective access, and it is a different measurement from theoretical configuration.

Answering it means correlating four things in one place: agent configuration from each AI platform, identity entitlements from your IdP and the SaaS apps, connector and tool metadata for what the agent can call, and runtime behavior for what actually happened. No single-vendor console produces that correlation, and native controls do not try to. This is also where individual findings combine into toxic combinations. An unmanaged shadow agent, with org-wide visibility, running on maker credentials, is not three medium issues. It is one critical exposure, and it sits in a large share of Copilot Studio and Agentforce deployments right now.

Native Versus External AI

Native agents are not automatically safer than external services. They inherit the vendor's infrastructure security, which is usually strong, and the vendor's access model, which is usually weak for agent use cases. An external service is easy to block at the identity provider. A native agent is hard to block because it is already inside the boundary.

Native Agents Versus Third-Party Integrations

A native agent is built into the platform by the vendor and runs on the platform's own authentication. A third-party integration is an outside service connecting through API, OAuth, or connector. The integration usually trips your existing procurement and IAM controls. The native agent usually does not, which is precisely why it needs less to activate and reaches more once it does.

Discovery is the first deterministic control in an agent security program, not a preliminary nice-to-have. Before you can reduce privilege, break up toxic combinations, or answer an audit question with evidence, you need one control plane spanning every AI platform in your environment. A working discovery approach answers a concrete set of questions:

• Which agents exist across Copilot, Agentforce, Bedrock, Vertex, Now Assist, Cortex, and your workflow builders?
• Who created each one, and is that person still active?
• What connectors and tools can each agent call?
• Which agents run in maker mode with fixed credentials?
• Which are org-wide or publicly reachable?
• What data has each agent actually touched at runtime, and as which identity?

That inventory becomes the input to everything after it: privilege reduction, governance, incident response, and the report the board asked for. Skip it, and the team stays in ghost-chasing mode, alerting on configuration with no runtime truth underneath.

A note on what "control" means here, because the market blurs it. Discovery and governance apply across every platform above. Runtime enforcement, the ability to stop an agent mid-action, is a narrower capability today. It exists for Microsoft Copilot and Claude and is on the roadmap for the rest. Obsidian does not sit inline in the request path as a gateway. It works as a decision engine the platform's own enforcement point consults, an Intel Inside model where the SaaS platform acts on the verdict. For every other platform, the honest and useful position is discover and govern now, enforce as the capability lands.

How to Protect Against the Risk

Sequence is the whole game. Start with cross-platform inventory. Map effective access next, meaning what each agent can actually reach, correlated to the service account and the objects and actions behind it, not what the config claims. Then find toxic combinations and reduce them. Only after that does runtime enforcement make sense, on the platforms where it is available, applied to the highest-risk actions. Jumping to enforcement without inventory buys coverage gaps you will not notice until the incident writes them up for you.

What Compliance Expects

The frameworks are converging on the same demand: know your agents. NIST's AI risk framework calls for inventory and risk assessment of AI systems. ISO's AI management standard calls for lifecycle governance. OWASP's guidance on low-code and no-code security and on agentic applications names the exact failure modes above, from account impersonation to excessive data access to action chaining. Enterprise auditors now ask the questions directly: what agents exist, what data do they reach, and what is the control model. An inventory built on runtime truth is what lets you answer without guessing.