By NHI Mgmt Group Editorial TeamBased on Obsidian Security: “GenAI Security Risks: Understanding Emerging Attack Vectors” (October 23, 2025)

TL;DR: Generative AI systems face prompt injection, data poisoning, model inversion, and identity and access control failures that can expose data and manipulate outputs, according to Obsidian Security. The practical issue is not just model safety but whether AI agents, tokens, and data-source access are governed as security-relevant identities before abuse becomes operational.


At a glance

What this is: This analysis explains how GenAI attack vectors combine prompt manipulation, poisoned data, and weak identity controls to undermine AI-driven business workflows.

Why it matters: It matters because AI agents and model-connected data sources now influence access, decisions, and confidentiality, so identity governance has to extend into AI runtime behaviour.


Context

Generative AI changes the security problem because the system is not just producing content, it is interpreting instructions, pulling data, and sometimes acting on behalf of users. That expands the attack surface from code and infrastructure into prompts, model behaviour, and the identities used to reach data sources.

Traditional security models struggle here because they were built to protect applications and networks, not to govern dynamic AI behaviours that can be redirected by malicious input or corrupted training data. The identity question is now central: when an AI agent can access systems, tokens, and customer data, it needs governance like any other privileged runtime actor.


Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: When do AI agent credentials create more risk than they reduce?

A: They create more risk when they are long-lived, over-scoped, hard to revoke, or copied into code and prompts. At that point the credential becomes a standing trust asset with unclear ownership. Security teams should reject any pattern that cannot be traced to a specific agent, environment, and revocation process.

Q: What do security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: Should organisations govern AI tools like third-party software dependencies?

A: Yes. External tools carry operational intent in the same way dependencies carry code risk. If the tool catalogue is not reviewed for provenance, scope, and hidden instructions, the agent inherits an untrusted supply chain at runtime. The governance model should therefore cover onboarding, approval, and continuous review.


Technical breakdown

Prompt injection turns natural language into a control bypass

Prompt injection works when attacker-controlled text is interpreted as higher-priority instruction than the system or developer prompt. Because large language models do not inherently separate trusted instructions from untrusted content, a malicious user can shape model behaviour, override guardrails, or coerce disclosure. In agentic workflows, the risk grows because the model may not just answer, but also call tools, retrieve data, or trigger downstream actions. The failure is architectural: the model is being asked to infer intent from language alone, while security expects deterministic policy enforcement. That mismatch makes content filtering necessary but insufficient.

Practical implication: enforce policy at the action layer, not just the prompt layer, for any AI system that can access tools or sensitive data.

Model poisoning changes the system before inference ever starts

Data poisoning attacks target the training or fine-tuning pipeline, not the live conversation. By inserting corrupted, biased, or backdoored examples, an attacker changes how the model behaves after deployment, often in ways that are difficult to trace back to a single malicious input. This is why model security is also supply chain security: the integrity of datasets, labels, and training sources determines the trustworthiness of the resulting model. Once poisoned behaviour is embedded, traditional runtime monitoring may detect symptoms but not the original compromise. Controls therefore need to cover provenance, validation, and post-training assurance.

Practical implication: validate training data provenance and maintain integrity checks across the full model lifecycle, not only in production.

Identity and access failures create the highest-confidence AI abuse path

The article’s most practical warning is that AI agents often hold broad access to multiple data sources while operating with weak identity governance. When those identities are over-permissioned, compromised tokens or delegated credentials become direct paths into enterprise systems, not just model misuse. This is where NHI governance meets AI security: tokens, service accounts, and agent identities are not peripheral plumbing, they are the control plane that determines blast radius. If AI access is not tightly scoped, monitored, and revocable, the model becomes an efficient interface to existing privileges rather than a protected workload.

Practical implication: treat AI agent credentials and delegated access as non-human identities subject to least privilege, review, and revocation controls.


Threat narrative

Attacker objective: The attacker aims to bend AI outputs and steal or misuse the access that the AI system already holds into enterprise data and workflows.

  1. Entry occurs through malicious prompt content, poisoned training inputs, or compromised third-party AI dependencies that alter model behaviour or trust decisions.
  2. Credential or access abuse follows when an AI agent or connected token is allowed to reach internal data sources with excessive privilege.
  3. Escalation happens when the manipulated model uses its access to reveal sensitive information, retrieve protected records, or trigger unintended downstream actions.
  4. Impact is data exposure, corrupted decisioning, and operational trust loss across customer-facing or internal AI workflows.
  • CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
  • Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI governance debt is now an identity problem, not only a model-risk problem. The article shows that the most damaging failures are not limited to bad outputs. They appear when AI systems hold access that was never governed as a security identity. That means the control gap is not just around prompts, but around delegated authority, token scope, and revocation discipline. Practitioners should treat AI access governance as a core part of identity architecture.

Prompt injection is a policy-boundary failure. The real issue is not whether a model can be tricked into saying something unsafe. The issue is whether the model can turn that trick into a protected action, such as data retrieval, system lookup, or workflow execution. Once tool use and retrieval are wired in, natural language becomes a path around security intent unless authorization is checked separately. Practitioners should separate generation from execution.

Model supply chains need the same scrutiny as software supply chains. Poisoned datasets, compromised third-party models, and unverified fine-tuning inputs can all shape behaviour long after deployment. That is why AI assurance cannot stop at runtime monitoring. The field needs provenance, integrity, and lifecycle controls that cover acquisition, training, deployment, and retirement. Practitioners should align AI assurance with supply chain governance, not treat it as an isolated AI team concern.

Blast-radius control is the decisive control variable for AI agents. The article makes clear that many AI risks become serious only when access is broad, persistent, and poorly segmented. If a compromised agent can touch multiple systems, the model becomes a multiplier for existing privilege. The governance question is no longer whether AI can work, but how much damage it can do when it is manipulated. Practitioners should narrow agent privilege before scaling deployment.

From our research library:

What this signals

AI agent governance has become a control-plane issue. Organisations cannot rely on classic application security if a model can reach data sources, invoke tools, and act with delegated authority. The practical shift is to govern access as a non-human identity lifecycle problem, where scoping, owner assignment, and revocation matter as much as model performance.

Prompt security and identity security are converging. Prompt injection matters because it can redirect something that already has access. The right response is to bind execution to policy, narrow tool permission, and expose anomalous access paths before they turn into a breach. Organisations that separate model output from action are much harder to abuse.

AI governance debt will show up in blast radius before it shows up in board reports. As AI systems take on more workflow responsibility, weak scoping and weak monitoring will be the first signs of trouble. Security leaders should look for overbroad connectors, reused tokens, and AI systems that can still reach sensitive data after the original use case has changed.


For practitioners

  • Scope AI agent access as non-human identity Inventory every agent, token, service account, and delegated connector. Map each one to a named owner, business purpose, data source, and explicit expiry condition so broad inherited access does not become permanent.
  • Separate prompt handling from tool execution Do not let model output directly control downstream actions. Require an authorization layer that checks requested tools, destinations, and data sensitivity before the agent can retrieve data or trigger workflows.
  • Test for prompt injection and jailbreak paths Add adversarial testing to pre-production and change management. Use realistic user inputs, retrieval content, and multi-step interactions to see whether the model can be coerced into disclosing data or bypassing guardrails.
  • Track provenance for datasets and third-party models Verify where training data, fine-tuning data, and model components came from. Keep approval records, integrity checks, and rollback paths so a compromised dependency can be isolated quickly.
  • Monitor AI behaviour for access anomalies Baseline response patterns, tool calls, and data access frequency so unusual spikes or atypical retrieval paths stand out. Connect those signals to SIEM and incident response workflows that can revoke tokens and disable connectors.

Key takeaways

  • Generative AI risk is no longer limited to unsafe content generation, because prompt manipulation, poisoned data, and overprivileged access can all become operational security failures.
  • The biggest exposure appears when AI agents inherit broad access to enterprise systems without lifecycle governance, especially where tokens and connectors can be reused or redirected.
  • Effective control depends on separating model behaviour from authorization, validating supply chain inputs, and treating AI credentials as non-human identities that must be scoped and revoked.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centers on AI agents gaining or misusing access to data sources and tools.
ASI06 — Memory & Context PoisoningPrompt injection and poisoned inputs alter the context the model uses to decide and act.
ASI04 — Agentic Supply Chain VulnerabilitiesThird-party models, datasets, and dependencies are a major exposure path in the article.
Recommendation — Apply ASI03 by binding agent actions to explicit authorization and least privilege. Test for ASI06 by validating prompts, retrieved context, and instruction boundaries before execution. Use ASI04 to verify the provenance and integrity of models, datasets, and connectors.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is fundamentally about governance structures for AI risk, access, and accountability.
MANAGE — Manage AI RisksThe article focuses on operational controls to reduce AI security and access risk.
Recommendation — Establish AI governance ownership, approval, and accountability before scaling agent deployment. Implement monitoring, containment, and remediation controls to manage AI risk throughout the lifecycle.

Key terms

  • Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
  • Model Inversion: Model inversion is an attack technique that tries to recover sensitive information from a model by querying it in a targeted way. The risk matters because information hidden in training data, prompts, or internal behaviour can sometimes be inferred from outputs rather than directly accessed.
  • Data Poisoning: The deliberate or accidental contamination of a data source that influences system behaviour. In AI environments, poisoned content can alter retrieval results, generated answers, or downstream decisions, which makes write access, change monitoring, and source integrity part of the identity control problem.
  • AI Agent Identity Governance: AI Agent Identity Governance is the set of policies, controls, and oversight used to manage how AI agents are identified, authorized, monitored, and retired. It defines who can create or operate an agent, what tools and data it may access, how its actions are logged, and how risk is reviewed across its lifecycle.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners apply governance patterns to AI agents and other non-human access paths.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org