What should organisations do when AI apps and automations are built inside the same platform?

Why This Matters for Security Teams

When AI apps and automations are built in the same platform, the security risk is not the build experience itself, it is the collision between fast deployment and broad backend reach. A workflow can look like a harmless business automation while quietly inheriting access to data stores, MCP endpoints, and service credentials that were never meant to be granted by default. That makes app approval and tool privilege approval two different decisions, even if the platform presents them as one. This is especially important for NHI governance because the identity at work is often a non-human one, not a human operator. Teams should treat the app as one object to approve and the workload identity, secrets, and tool permissions as a second object to govern. Guidance from NIST Cybersecurity Framework 2.0 still applies here: asset visibility, access control, and continuous monitoring need to follow the actual privilege boundary, not the platform menu. NHIMG research shows why this matters in practice. In the DeepSeek breach, exposed secrets and database access turned a product issue into a data exposure event, and the JetBrains GitHub plugin token exposure case shows how easily tooling ecosystems can spread trust too widely. In practice, many security teams encounter overprivileged automations only after a workflow has already touched sensitive systems rather than through intentional design review.

How It Works in Practice

The practical control is to split the approval path into two layers. First, approve the application or automation for business use. Second, approve each tool, connector, MCP integration, secret, and backend service it can touch. This is where RBAC alone is usually too coarse, because roles describe who can use the platform, not what an autonomous workflow should be allowed to do at runtime. Current guidance suggests combining platform governance with workload identity, JIT credentials, and policy checks at request time. A workflow should present cryptographic proof of identity, then receive only the minimum secret or token required for the task, with short TTLs and automatic revocation after completion. That is more aligned with zero standing privilege than with long-lived tokens sitting in a secrets vault. For implementation patterns, teams often pair policy-as-code with runtime enforcement, using models from NIST Cybersecurity Framework 2.0 and the emerging AI control thinking in NIST Cybersecurity Framework 2.0, while using workload identity approaches such as SPIFFE-style identity for non-human workloads. A workable operating model usually includes:

• separate approval records for the app, the data source, and the tool credential
• explicit owner assignment for each connector and backend service
• short-lived secrets instead of reusable static tokens
• logging that ties every tool call to the workload identity that made it
• periodic review of whether the automation still needs each privilege

This is also where NHIMG research is useful. The Ultimate Guide to NHIs — The NHI Market frames the broader identity problem, while leaked secret patterns in the DeepSeek breach reinforce why secret sprawl is a live risk. These controls tend to break down when a single platform lets business users chain multiple connectors without runtime policy enforcement because the platform then becomes the privilege boundary instead of the workload identity.

Common Variations and Edge Cases

Tighter approval and privilege separation often increases friction, so organisations have to balance developer speed against blast-radius reduction. That tradeoff is real, especially in low-code platforms where teams expect to publish automations quickly. The main exception is low-risk, read-only workflows, where some organisations allow lighter review if the automation only touches non-sensitive data and no secrets are issued. Even then, best practice is evolving, and there is no universal standard for this yet. For higher-risk cases, such as agents that can write records, invoke MCP tools, or trigger downstream actions, static approval at build time is not enough because the same workflow may behave differently depending on runtime context, input, and chained tool calls. That is why NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs — The NHI Market both point toward continuous control rather than one-time approval. A final edge case is shared-platform governance across engineering, operations, and business teams. When each group can build the same workflow shape, ownership often becomes ambiguous, and no one feels accountable for the secret lifecycle or the access review. That is when separation of duties matters most, because the approval for the app does not automatically justify the privilege to the data behind it.

Related resources from NHI Mgmt Group

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