An in-platform agent is an AI workload that executes inside a SaaS or data platform rather than calling out from an external system. Its security posture is determined by the platform role it inherits, the data it can reach, and the connectors it can invoke.
Expanded Definition
An in-platform agent is not just an AI feature running somewhere in the cloud. It is an autonomous workload that inherits the trust boundary, permissions model, and audit controls of the SaaS or data platform it lives inside. That makes it materially different from an external agent that reaches into the platform through APIs, because the platform itself becomes part of the agent’s execution environment.
In NHI security, the critical question is not only what the agent can do, but what identity it runs as, what tokens it can mint or reuse, and whether it can traverse datasets, workflows, or connectors beyond the intended scope. Definitions vary across vendors, especially when platforms blur the line between embedded assistants, workflow automations, and fully autonomous agents, so governance teams should anchor the term to execution context and effective privilege rather than product labels. The risk model aligns closely with the control concerns discussed in OWASP Top 10 for Agentic Applications 2026 and the assurance lens of the NIST AI Risk Management Framework.
The most common misapplication is treating an in-platform agent like a harmless user interface add-on, which occurs when its inherited platform role is broader than the business owner understands.
Examples and Use Cases
Implementing in-platform agents rigorously often introduces a governance tradeoff: the closer the agent sits to enterprise data, the more useful it becomes, but the harder it is to constrain and observe its effective blast radius.
- A customer support agent embedded in a CRM drafts case responses using live account history, but it should be limited to read-only access on accounts it services and be blocked from exporting data through connectors.
- A finance assistant inside a SaaS planning platform can reconcile invoices and flag anomalies, yet it must not inherit the human approver’s privileges or gain blanket access to payment workflows.
- A data platform agent generates SQL, summarizes tables, and triggers downstream jobs. Its access should be evaluated as an NHI, not as a normal user shortcut, because the execution context can span multiple datasets and tools.
- Post-incident analysis often starts after an embedded automation has overreached. The patterns described in OWASP NHI Top 10 are especially relevant when platform-native agents are allowed to invoke connectors without explicit policy boundaries.
- Security teams comparing embedded and external models may use the MITRE ATLAS adversarial AI threat matrix to map prompt injection, tool misuse, and privilege escalation paths.
In practice, in-platform agents are most common in SaaS copilots, data warehouse assistants, workflow automations, and case-management platforms where the agent can both interpret content and act on it.
Why It Matters in NHI Security
In-platform agents matter because they collapse the distance between the identity, the data, and the action. When the agent is compromised, the attacker does not need to break into a separate service and then pivot inward. They may be able to operate inside the trusted platform boundary using legitimate permissions, which makes detection and containment slower.
This is why NHI governance cannot stop at sign-in controls. The organization must understand connector scope, delegated authority, secret handling, and revocation paths for every embedded agent. NHIMG research shows that 97% of NHIs carry excessive privileges, and 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, underscoring how often platform trust exceeds actual need. The same pattern is visible in incidents discussed in AI LLM hijack breach and Moltbook AI agent keys breach, where control failures were tied to misplaced trust and weak containment.
Organisations typically encounter the severity of an in-platform agent only after a connector is abused, a sensitive dataset is exposed, or an autonomous action is executed outside business intent, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Embedded agents often fail through secret sprawl and excessive platform permissions. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems require explicit controls for tool use, autonomy, and privilege boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed to keep embedded agents within least-privilege bounds. |
Treat platform-native agents as autonomous actors and constrain their tool execution paths.
