Should organisations treat embedded AI and homegrown AI the same way?

Why This Matters for Security Teams

embedded ai and homegrown AI are both risky, but not in the same way. Embedded AI usually arrives inside a SaaS control plane, so the organisation inherits vendor defaults, shared tenancy assumptions, and limited visibility into how data is handled. Homegrown AI, by contrast, creates local accountability gaps across model access, retrieval layers, and service identities. The common mistake is to apply one review pattern everywhere and assume the blast radius is comparable.

Security teams should standardise the governance model while still separating the identity path, data path, and execution path for each system. That means checking who can call the model, what context is injected, where secrets live, and how outputs are used downstream. Current guidance aligns with the NIST Cybersecurity Framework 2.0, which emphasises asset visibility, governance, and continuous risk handling. It also fits the risk patterns described in DeepSeek breach, where exposed data paths and weak containment amplified impact.

In practice, many security teams encounter identity sprawl and data leakage only after an AI workflow has already been placed in production, rather than through intentional design.

How It Works in Practice

The practical difference starts with control points. Embedded AI should be reviewed as part of the SaaS risk surface: tenant boundaries, admin roles, data retention, logging, and whether the vendor can train on customer inputs. Homegrown AI needs deeper engineering review because the organisation owns the retrieval layer, orchestration logic, secrets handling, and workload identity. That makes the review model similar, but the questions are not identical.

For embedded AI, teams should validate whether the product exposes only approved data and whether API tokens, service accounts, and connectors are scoped tightly enough to avoid overreach. For homegrown AI, teams should map every dependency from prompt entry to tool execution. That includes external APIs, vector stores, and internal services that may be reachable through NIST Cybersecurity Framework 2.0 aligned access controls and the governance principles reflected in DeepSeek breach analysis. Where a system uses secrets for retrieval or agentic tooling, those secrets should be treated as NHIs, not as a side issue.

• Use one control baseline for both classes, then branch the checklist by ownership and deployment model.
• Require workload identity for homegrown AI services so the caller is cryptographically identifiable.
• Review prompt injection, connector scope, and output handling separately from model selection.
• Apply RBAC to administrators, but do not confuse admin roles with runtime authorisation for AI actions.
• Track JIT credential use and ephemeral secrets where systems can act autonomously.

This guidance tends to break down in multi-tenant SaaS environments where the provider does not expose enough telemetry to distinguish model behaviour from platform behaviour.

Common Variations and Edge Cases

Tighter review often increases operational overhead, requiring organisations to balance speed of adoption against the cost of deeper inspection. That tradeoff is especially visible when embedded AI is enabled by default inside collaboration tools, or when homegrown AI is built quickly for a narrow business use case and later expands into broader workflow automation.

There is no universal standard for classifying every AI feature yet, so best practice is evolving. A feature that looks embedded may actually rely on custom prompts, local retrieval, and internally managed secrets, which makes it behave more like homegrown AI from a risk perspective. The reverse is also true: a custom application can be low-risk if it has no tool access, no sensitive retrieval, and strict data isolation. The important question is not who built the interface, but who controls execution and where identity, secrets, and data converge.

Teams should also avoid treating all AI outputs as equal. Some systems only summarise content, while others can write to tickets, trigger transactions, or invoke external APIs. Those second-order actions are where identity design matters most. In those cases, governance should reflect workload identity, short-lived credentials, and explicit runtime policy checks, not just static approval at deployment time. The lessons in DeepSeek breach show how quickly weak boundaries become operational exposure when AI systems are given broad access.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• When should organisations use AI to help manage NHIs?
• How can organisations prevent AI agents from becoming overprivileged?
• How can organisations govern AI agents that use service accounts and tokens?