Why do build-your-own AI platforms increase identity and data security risk?

Why This Matters for Security Teams

Build-your-own AI platforms expand risk because they blur the line between application logic, data access, and identity governance. A user assembling a workflow may unintentionally connect models, tools, and datasets in ways that bypass normal review paths, creating broad access with little visibility. That pattern is consistent with what NHIMG documents in the Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks.

The security issue is not just that these platforms can touch sensitive data. It is that they often introduce new non-human identities, tokens, connectors, and service accounts faster than security teams can classify or govern them. When platforms allow self-service agent creation, the identity layer becomes part of the product surface, not just an infrastructure concern. That makes misconfiguration, shadow integrations, and over-permissioned automations much more likely than in a conventional app stack. The risk is amplified in environments already struggling with secret sprawl, as highlighted in NHIMG’s Top 10 NHI Issues analysis and the external control baseline in the NIST Cybersecurity Framework 2.0.

In practice, many security teams encounter excessive access only after a workflow has already chained into production data and external services.

How It Works in Practice

These platforms usually let business users or developers compose prompts, retrieval sources, actions, and integrations without designing the identity model first. That is where the failure starts. If each connector inherits the same broad API token, the platform effectively turns one approved user action into many downstream privileges. For build-your-own systems, current guidance suggests treating every workflow as a distinct workload identity, not as an extension of the person who clicked “publish.”

That means separating three layers: who initiated the workflow, what the platform is allowed to do, and what each tool call is permitted to access. In practice, security teams should prefer workload identity, short-lived credentials, and runtime policy decisions over static access rules. The better pattern is:

• issue ephemeral credentials per task or session, not long-lived platform-wide keys;
• bind each agent or workflow to a distinct workload identity;
• evaluate permissions at request time based on tool, data class, and context;
• log every connector, secret, and retrieval path for review and revocation.

That approach aligns with the NHI lifecycle principles in the Ultimate Guide to NHIs and the practical control expectations in the CSA Cloud Controls Matrix. It also fits the NIST view that identity assurance and access enforcement should be continuous, not one-time approvals. Build-your-own AI platforms become safer when every secret, token, and connector has a clear owner, a short TTL, and a defined revocation path. These controls tend to break down when the platform allows user-created plugins or unmanaged third-party connectors because each new integration becomes a hidden trust boundary.

Common Variations and Edge Cases

Tighter identity control often increases setup overhead, requiring organisations to balance speed of experimentation against the cost of governance. That tradeoff is real, especially when product teams want rapid prototyping and security teams need predictable access boundaries. Best practice is evolving, but there is no universal standard for this yet across agent builders, data gateways, and orchestration tools.

Some environments can tolerate broader access in low-risk sandboxes, but that exception should not leak into production. The most common edge case is a platform that is secure at the app layer but weak at the connector layer, where a single plugin can read mailboxes, repositories, or ticketing systems. Another common issue is shared secrets for many workflows, which makes forensic attribution and revocation nearly impossible. NHIMG’s 52 NHI Breaches Analysis shows how often identity abuse follows exactly this pattern, and the same lesson appears in the McKinsey AI platform breach: once a workflow has broad access, the blast radius is determined by identity design, not just by model quality.

For regulated or high-trust environments, the safer position is to restrict build-your-own features until the organisation can prove least privilege, secret rotation, and approval workflows for every data source.

Related resources from NHI Mgmt Group

• Why do generative AI tools increase data security risk?
• Why do AI helpdesks and security tools increase identity governance risk?
• Why do AI-assisted security workflows increase identity risk in cloud environments?
• Why do AI prompts create identity and data-security risk?