AI security best practices still leave agent identity gaps

At a glance

What this is: This is a blog post on AI security best practices, with a key finding that AI security must extend beyond models to APIs, data, monitoring, governance and shadow AI.

Why it matters: It matters because AI systems increasingly depend on identities, tokens and access paths that IAM, PAM and NHI programmes must govern alongside traditional application and cloud controls.

👉 Read Akto's blog on AI security best practices for models, APIs and enterprise systems

Context

AI security best practices are often written as a checklist of technical safeguards, but that framing can hide the real governance problem. Once AI systems connect to APIs, external datasets, and enterprise workflows, the security boundary shifts from the model itself to the identities and permissions around it, including service accounts, API keys, tokens and delegated access.

Akto’s article is a broad practitioner guide, not a deep technical research paper, but the overlap with identity is genuine. The strongest controls in this space are rarely model-specific on their own. They depend on access scope, authentication, monitoring, and the ability to distinguish authorised AI use from shadow AI running outside governance.

Key questions

Q: How should security teams govern AI experimentation without slowing delivery?

A: Use lane-based governance. Low-risk experiments belong in isolated sandboxes with minimal guardrails, while managed and critical workloads should inherit progressively stronger controls. The goal is to make experimentation safe by default, not to force every AI use case through production-grade approval gates before value is proven.

Q: Why do AI systems create identity risk as well as model risk?

A: Because AI systems rarely act alone. They depend on service accounts, API tokens, cloud permissions, and data access paths, which means a model can behave safely while its identity layer is over-privileged. Treating AI risk as only a model problem misses the access surface where misuse and lateral movement usually begin.

Q: What breaks when shadow AI is not discovered early?

A: Teams lose sight of which agents exist, what they can reach, and which credentials they use. That creates blind spots in audit trails, incident response, and offboarding, especially when agents are created locally or disappear after a single task. Discovery failure becomes governance failure once the identity cannot be traced back to an owner.

Q: Should AI governance sit with security, IAM or the business?

A: It should be shared, with security setting control requirements, IAM managing identities and permissions, and the business owning approved use cases and risk acceptance. AI governance fails when it is treated as a side project because the controls span multiple teams. Clear ownership, access review and change control are the minimum coordination points.

Technical breakdown

Data poisoning and training data governance

Data poisoning occurs when attackers influence model behaviour by inserting malicious or misleading content into training or fine-tuning data. The control problem is not just data quality, but data provenance, source trust and change detection across the pipeline. In practice, poisoned inputs can alter predictions, distort downstream decisions, or reduce confidence in model outputs. Security teams need visibility into which sources feed a model, who can modify them, and how anomalies are detected before the data reaches training or retrieval stages.

Practical implication: apply source allowlisting, dataset integrity checks and approval workflows to every training or retrieval feed.

API protection, authentication and prompt injection

AI systems usually expose their most valuable functions through APIs, which makes authentication and input validation central to security. Prompt injection is one example of input abuse, where attacker-controlled text alters how the system responds or what tools it uses. In agentic environments, the same issue can become a control-plane problem if the model can call tools, query data or trigger workflows based on untrusted input. Rate limits, strict schema validation and scoped credentials all reduce the likelihood that a malformed request becomes an unsafe action.

Practical implication: treat AI APIs as privileged interfaces and enforce schema validation, rate limiting and least-privilege tokens.

Shadow AI and monitoring for unauthorised use

Shadow AI refers to AI tools, agents or integrations that operate outside formal security oversight. This is not simply an inventory problem. It is a governance problem because unmanaged systems can access sensitive data, create unauthorised outputs, or embed unreviewed third-party components into business processes. Continuous monitoring should therefore cover usage patterns, model drift, unusual data access and newly discovered integrations. In mature environments, discovery must extend to the identities used by AI systems, not just the models themselves.

Practical implication: discover AI services, map their identities and monitor for unauthorised connections before they expand the attack surface.

Threat narrative

Attacker objective: The attacker aims to distort AI behaviour, expose sensitive data or use the AI system as a trusted path into broader enterprise workflows.

1. Entry occurs when attackers abuse exposed AI APIs, untrusted training inputs or unmanaged integrations to reach the system boundary.
2. Escalation follows when the model, agent or pipeline processes malicious content, accesses broader data than intended, or uses over-scoped credentials to call adjacent tools.
3. Impact arrives when outputs are manipulated, sensitive data is exposed, or the AI system is used as a trusted pathway into other enterprise services.

NHI Mgmt Group analysis

AI security best practice is now an identity governance problem as much as a model security problem. The article is framed around data poisoning, monitoring and governance, but the practical risk surface sits in the identities that power AI systems. API keys, service accounts and delegated tokens can be the easiest route from a model to enterprise data. Practitioners should treat AI security as a combined model and identity control problem.

Shadow AI creates governance debt faster than traditional software sprawl. Unauthorised AI tools do not just bypass policy, they bypass ownership, logging and lifecycle controls. That means the first failure is usually not technical exploitation but incomplete discovery. For identity teams, the named concept is AI identity blind spot: systems that are operationally active but absent from entitlement, review and offboarding processes. Practitioners should build discovery and registration into AI governance from day one.

API protection is the real enforcement layer for most enterprise AI systems. The article correctly treats APIs as the interface to protect, but the deeper issue is that AI workflows often reuse credentials with broader access than the task requires. That breaks the least-privilege assumption IAM depends on. In NHI terms, AI systems should be governed like any other workload identity with scoped access, expiry, and observability. Practitioners should align AI API controls with NHI lifecycle management.

Governance without operational monitoring will not contain AI risk. Explainability, accountability and policy are necessary, but they do not stop an agent from using an over-permissioned path or a malicious input from changing runtime behaviour. The market is moving toward continuous controls because static review cannot keep pace with AI change velocity. Practitioners should expect governance frameworks to converge with runtime detection, access analytics and NHI oversight.

AI security programmes that ignore human identity still miss the approval layer. Many AI failures begin with legitimate users enabling unsafe integrations, uploading sensitive data, or granting access to tools they do not fully understand. That makes education, approval workflows and role-based restrictions part of the control stack, not soft policy extras. Practitioners should connect AI governance to IAM, change management and access review rather than treating it as a separate discipline.

What this signals

The immediate programme signal is that AI security and identity governance are converging. If your team cannot enumerate which AI services exist, what they can access, and which human or machine owners approve changes, then policy will lag reality. The practical response is to connect discovery, entitlement review and runtime monitoring into one control loop, using the same discipline applied to other privileged workloads.

AI identity blind spot: the organisations most exposed are not necessarily the ones with the most advanced models, but the ones with the least visibility into how those models are connected. That pattern shows up whenever AI tools are adopted faster than access governance matures. Practitioners should treat AI registration, credential scope and offboarding as baseline security operations, not optional hygiene. See OWASP Agentic Applications Top 10 for the broader threat model.

For practitioners

• Implement scoped credentials for AI services Assign AI workloads the narrowest possible API keys, service accounts and tokens, then rotate and revoke them on a defined lifecycle. Avoid reusing human admin credentials for model endpoints or tool connectors. The goal is to keep each AI identity task-bound and auditable.
• Register every AI integration in one inventory Create a single register for models, agents, plugins, retrieval sources and external APIs, including the identities each one uses. Tie that inventory to access review, owner assignment and offboarding so shadow AI cannot persist outside governance.
• Validate inputs before they reach model or tools Apply schema validation, content filtering and tool permission checks at the API layer before prompts or documents reach the model. This reduces the chance that malicious input can redirect the system or trigger unauthorised downstream actions.
• Monitor AI behaviour for abnormal access patterns Track unusual data access, unexpected tool calls, and changes in model output behaviour that may indicate poisoning, prompt abuse or credential misuse. Feed those signals into SOC workflows so AI incidents are triaged like other privileged access events.
• Tie AI governance to access review cycles Make AI system approvals part of IAM and GRC review, including who can deploy, modify and connect each model or agent. Revalidate ownership whenever the model changes, the data source changes, or a new tool is added.

Key takeaways

• AI security best practices are incomplete if they stop at model protection and ignore the identities, APIs and tokens that let systems act.
• Shadow AI, over-scoped credentials and weak input controls create the conditions for data exposure, prompt abuse and unauthorised workflow execution.
• Practitioners should govern AI with the same lifecycle discipline used for other privileged workloads: discovery, scope control, monitoring and offboarding.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• 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.
• AI Service Identity: An AI service identity is a machine credential that allows a model, agent, or supporting workflow to authenticate to tools, data sources, or APIs. It behaves like a non-human identity because it can be issued, scoped, monitored, and revoked independently of any person.
• 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.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step AI security best practices across data poisoning, governance, monitoring and API protection.
• Practical guidance on securing AI models, APIs and enterprise systems across the development lifecycle.
• Operational examples for testing, discovery and control validation in AI security programmes.
• The vendor's own framing of agentic AI guardrails and API security implementation details.

👉 Akto's full post covers the best-practice checklist, implementation themes and agentic security positioning in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle and secrets management for practitioners building modern control planes. It helps security teams connect identity discipline to the broader programmes that now govern AI-enabled systems.