What breaks when AI is bolted onto existing applications instead of using AI-first architecture?

Why This Matters for Security Teams

When AI is bolted onto an existing application, the security model usually keeps pretending that the app is the system of record for access. That assumption breaks as soon as an orchestrator can read, decide, call tools, and pass data between services. The real privilege is no longer the role on one screen, but the combined ability to move across workflows, datasets, and APIs. That is why application-centric reviews often miss the true blast radius.

This is especially dangerous for secrets-heavy environments. NHIMG research on The State of Secrets in AppSec shows that organisations still carry fragmented secrets management and slow remediation, which becomes more severe when AI components can surface, chain, or reuse credentials across multiple systems. Security teams should also anchor this discussion to the NIST Cybersecurity Framework 2.0, because AI changes how assets, access, and monitoring need to be mapped across the environment.

In practice, many security teams encounter privilege sprawl only after an AI feature has already stitched together access that no single owner intended.

How It Works in Practice

AI-first architecture changes the control point from the app wrapper to the workflow itself. Instead of granting a broad application role and hoping the embedded model behaves, teams define what the AI system is allowed to do at runtime, with context from user intent, task scope, data sensitivity, and downstream effects. This is where current guidance suggests moving toward intent-based authorisation, short-lived credentials, and workload identity rather than static app permissions.

Practically, that means the orchestrator should authenticate as a workload, not as a generic service account that lives for months. Standards such as SPIFFE support workload identity, while policy engines like OPA or Cedar can evaluate whether a specific tool call is acceptable at request time. A secure pattern is to issue just-in-time credentials per task, scope them to one action set, and revoke them when the task completes. That reduces the risk that an AI agent can reuse a token after it has moved on to a different objective.

• Use workload identity for the agent or orchestrator, not shared app credentials.
• Evaluate policy at runtime, based on action, data class, and destination system.
• Issue ephemeral secrets for the minimum task window, then revoke automatically.
• Log the full decision path, not only the front-end user request.

For practitioner context, NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs illustrates how quickly exposed credentials become exploitable once an AI system can reach them. This is why AI-first design must treat the orchestrator as an active security boundary, not just a feature layer. These controls tend to break down when legacy applications hardcode service-to-service trust, because the AI layer inherits opaque privileges it cannot safely constrain.

Common Variations and Edge Cases

Tighter AI control often increases integration overhead, requiring organisations to balance safer runtime decisions against developer friction and legacy complexity. That tradeoff is real, especially where teams are retrofitting AI into customer portals, ticketing systems, or internal copilots that already rely on broad roles and persistent secrets.

Current guidance suggests three common edge cases. First, read-only AI use cases are often treated as low risk, but the model can still exfiltrate sensitive context through prompts, logs, or retrieval pipelines. Second, multi-step workflows may appear safe at the app level while still enabling unsafe cross-system composition. Third, shadow connectors and plugin ecosystems can create hidden pathways that bypass the intended policy layer entirely.

There is no universal standard for this yet, but the direction of travel is clear: AI-first architecture needs continuous authorisation, not one-time app onboarding. Security teams should pair this with governance from NIST Cybersecurity Framework 2.0 and emerging AI control guidance from NHIMG research such as the State of Secrets in AppSec when assessing whether credentials, prompts, and tool access are all being governed as one system.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• What breaks when prompt injection reaches a tool-using AI agent?
• What breaks when organisations try to retrofit IAM controls onto AI agents?
• What breaks when spreadsheet formulas can reach host execution?