How do external, embedded, and homegrown AI systems change access governance?

How deployment pattern changes the access-control problem

External, embedded, and homegrown AI systems do not just differ in where the model runs, they differ in where access decisions are made and who can change them. That matters because access governance is not only about a login or a policy file, it is about the full path from user intent to data access, tool use, and administrative override. Once the deployment pattern changes, the controls that need ownership, review, and monitoring change with it.

For external AI tools, the main governance issue is often unsanctioned adoption, because users can move sensitive work into a service the security team does not directly operate. That makes inventory, approved-use boundaries, and data handling rules more important than model tuning. For embedded ai inside SaaS, the decision boundary shifts into the vendor workflow, so access governance has to cover the application role model, tenant settings, and the way the feature inherits the host system's permissions. For homegrown AI, the control plane expands further into infrastructure, data platforms, and model operations, which means governance must cover the environment, not just the end user or the app layer. IAM and IGA Basics is useful here because the core issue is still how identity, authorization, and entitlement control are applied across different operating models.

That distinction also affects how you define the protected asset. In an external tool, the asset may be the prompt, the uploaded document, or the downstream connector that the service can reach. In an embedded feature, the asset may be the SaaS record set and the permission model already attached to the tenant. In a homegrown system, the asset expands to datasets, vector stores, APIs, orchestration jobs, model endpoints, and the infrastructure that can run or modify them. A single policy statement cannot govern all three well unless it is translated into the deployment pattern and the actual control surfaces involved.

Where governance breaks when all AI is treated the same

The most common failure is overgeneralisation. Teams write one acceptable-use rule, one data classification rule, or one review process and assume it covers every AI pattern. It usually does not, because the risk is not identical across the three models. External tools create visibility gaps, embedded tools create inherited access risk, and homegrown systems create broad administrative and operational exposure. Ultimate Guide to NHIs, key challenges and risks aligns with this control problem because the hard part is not only who can use the system, but who can see, govern, and revoke the access behind it.

External tools are often governed as a user productivity issue, which is too narrow. If staff can paste regulated data or connect third-party data sources into an outside service, the organisation has a governance problem even if no formal integration exists. Embedded AI is often misread as “just another SaaS feature,” but once the feature can infer, recommend, retrieve, or act on tenant data, the effective access path has changed and permission review must include the AI capability itself. Homegrown systems are frequently treated as an engineering project first and a governance issue second, yet the model pipeline can be as sensitive as any privileged production service because it can expose training data, inference data, secrets, or administrative endpoints. Ultimate Guide to NHIs, lifecycle processes for managing NHIs is relevant to the homegrown pattern because lifecycle control, not just deployment, determines whether access stays bounded over time.

The practical consequence is that governance owners should map AI use by control domain, not by novelty. External use needs intake and data-sharing control. Embedded use needs SaaS configuration, tenant governance, and permission inheritance review. Homegrown use needs platform, data, and operations controls that cover build, deploy, operate, and retire. If you do not separate those patterns, you will either overcontrol low-risk usage or undercontrol the high-risk one.

What to govern in each pattern

External AI systems should be governed through approved-use rules, data classification boundaries, and explicit review of outbound data flows. The important question is whether the tool is allowed to see the information in the first place, because once the prompt leaves the enterprise boundary, the organisation may lose direct control over retention, reuse, and secondary processing. Access Reviews and Certification Guide is useful where the key governance action is deciding which people, groups, or non-human access paths should keep access to sensitive data or connected tools.

Embedded AI systems should be governed through SaaS administration, feature entitlements, and workflow-level authorization. Here the critical issue is often not whether the vendor has an AI feature, but whether that feature can act on the same data and permissions that the underlying application already has. Access review should therefore include the embedded feature, not just the base application license. Where the vendor exposes separate knobs for training, logging, connector scope, or cross-workspace access, those settings become part of access governance, not just privacy or procurement.

Homegrown AI systems should be governed through a broader control stack: infrastructure access, data platform permissions, service identities, model operations, and administrative override. That means the governance model must cover who can deploy, retrain, reconfigure, query, or connect the system to sensitive datasets. The operational question is simple: can the team prove that the AI system only has the permissions it needs, and can those permissions be reviewed or removed without breaking the environment? IGA Buyer's Guide is a practical navigation point for the broader entitlement and connector problem that appears when AI systems need governed access across multiple platforms.

Risk and Threat Considerations

AI access governance fails most often when teams trust the deployment label more than the actual access path. An external tool can become a shadow data sink, an embedded feature can inherit excessive tenant privileges, and a homegrown system can accumulate broad operational access that no one rechecks after launch.

Failure mechanism: Sensitive data, connectors, or action rights are granted to an AI system without a deployment-specific review of scope, inheritance, or revocation, so the system ends up with more access than the business intended.

Impact: The result can be data leakage, unauthorized actions, difficult incident scoping, and access that survives long after the original business need has changed.

Practitioner Guidance

What to verify: For every AI use case, verify the deployment pattern first, then verify which permissions are native, inherited, or externally granted. If you cannot explain where the access decision is made, the governance model is too vague to rely on.

Decision rule: If the system is external, govern data egress and approved use; if it is embedded, govern tenant settings and application entitlements; if it is homegrown, govern infrastructure, data, and model operations together. Do not let a single policy template stand in for those different control points.

Practitioner takeaway: Access governance for AI works only when the control surface matches the deployment pattern, because the real risk is not “AI in general” but the specific way authority, data, and action rights are distributed.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• What is the difference between role-based access and API key governance for NHI security?
• Why is single-provider AI agent governance not enough for enterprise security?