AI security best practices still leave agent identity gaps

At a glance

What this is: Akto frames AI security best practices as a layered control problem, but its own guidance shows a persistent gap around who or what is allowed to act inside agentic AI systems.

Why it matters: IAM, PAM, and AI security teams need to treat agent identity as a governance boundary, because securing models without governing agent privileges leaves a material path for misuse.

Context

AI security is not just model hardening. It also depends on deciding which identities can train, call, modify, or delegate actions inside the AI stack, and that is where many best-practice lists stay too general.

The article groups data poisoning, API protection, supply chain checks, governance, monitoring, and privacy together, but the practical weakness is that these controls often stop at the model or pipeline edge. For agentic AI, the identity of the acting system becomes the control plane, so access governance has to move closer to issuance, authorization, and revocation.

Key questions

Q: Where do AI security best practices fail when agents can act independently?

A: They fail when the programme treats the model as the main control boundary and ignores the identity of the acting system. If an agent can call tools, access data, or trigger workflows, then privilege scope, ownership, and revocation matter as much as model safety or monitoring.

Q: Why do agent credentials increase risk even when APIs are protected?

A: Because API protection only proves the caller reached the endpoint, not that the caller should be allowed to perform the business action. An overprivileged agent can still misuse valid access, so teams need action-level authorisation and short-lived permissions, not just authentication and rate limits.

Q: What are the signs that agent authority is failing in production?

A: Look for long-lived tokens, shared credentials, missing approval logs, and audit trails that cannot attribute an action to the agent itself. If a team cannot tell who or what issued a delete, config change, or external message, governance is already failing.

Q: How should organisations govern shadow AI without blocking legitimate use?

A: Start with approved-use policy, tool inventory, and data classification. Then require that any AI system handling internal information has named owners, logged access, and defined credential paths. The goal is not prohibition, but visibility and control. If a tool cannot be inventoried or monitored, it should not process sensitive data.

Technical breakdown

Why agent identity is the missing control plane

Agentic AI systems do not behave like static applications. They may request tools, access APIs, and act on behalf of users or processes, which makes identity and privilege the operational boundary, not a side issue. If security controls only protect model inputs, output quality, or the CI/CD pipeline, they miss the question of whether an agent should have been allowed to act at all. In practice, that means treating agent credentials, delegated scopes, and runtime authorisation as first-class controls alongside model safeguards.

Practical implication: Map every AI agent to an explicit identity, privilege scope, and revocation path before allowing production access.

Why API protection alone does not govern agent risk

The article is right that APIs are a major attack surface, but API security and agent governance are not the same thing. An API can be authenticated and rate limited while an overprivileged agent still has valid access to sensitive flows, delegated actions, or downstream systems. The deeper issue is not just whether the endpoint is protected, but whether the calling identity is entitled to perform the requested action in the current context. That is an authorisation and lifecycle problem as much as a transport or validation problem.

Practical implication: Pair API controls with privilege scoping, short-lived access, and action-level authorisation for every agent call.

What governance looks like when the system can act

The governance model for agentic AI has to include auditability, ownership, and change control for non-human actors. A static policy set is not enough if agents can be added, retrained, repurposed, or linked to tools faster than review cycles can catch up. This is where lifecycle controls matter: inventory, approval, segregation of duties, monitoring, and revocation should apply to agents just as they do to privileged human access. Without that, shadow AI becomes a governance blind spot rather than a model-risk issue.

Practical implication: Build agent inventory and approval controls into AI governance so every agent has an accountable owner and lifecycle record.

NHI Mgmt Group analysis

Agent identity is the control plane, not a niche subtopic: once an AI system can decide when to call tools or services, identity governance becomes the boundary that determines blast radius. Best-practice lists that stop at model safety, monitoring, or data hygiene leave the acting entity under-governed. The practitioner takeaway is to treat agent identity as part of core IAM and PAM design, not as an AI add-on.

Security guidance that emphasises APIs without entitlement review is incomplete: API authentication can be sound while the connected agent still has excessive or poorly bounded authority. That gap matters because agentic systems turn valid credentials into execution capability across workflows, not just access to a single endpoint. The practitioner conclusion is that action-level authorisation must sit beside API protection.

Shadow AI is a governance failure before it is a technical one: undiscovered agents, embedded automations, and delegated workflows create inventories that traditional review processes do not see. Once those actors are outside ownership and lifecycle control, compliance, monitoring, and incident response all lose precision. The practitioner conclusion is that agent discovery and offboarding must be treated as governance fundamentals.

AI governance debt grows when privilege becomes reusable: the more an agent’s access can be inherited, re-used, or left standing across tasks, the more the programme accumulates hidden exposure. That is the same class of failure IAM teams learned with service accounts and long-lived secrets, now amplified by autonomous execution. The practitioner conclusion is to reduce standing agent authority before scaling deployment.

AI security frameworks need to converge around identity, not duplicate around tools: data poisoning, supply chain integrity, monitoring, and privacy all matter, but they do not replace identity governance. The field is heading toward a model where agent trust, delegated authority, and revocation discipline sit alongside model assurance. The practitioner conclusion is to align AI security controls with IAM and PAM ownership early.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agent identity governance is now a prerequisite for safe AI scale: many teams will keep adding model, data, and API controls, but the real operational risk sits in who or what can act inside the environment. The programme consequence is that IAM, PAM, and AI governance must converge around non-human actors before adoption accelerates further.

AI governance debt: this is the accumulation of unmanaged agent access, ownership gaps, and delegated privileges that build faster than review cycles can clear them. Once that debt exists, monitoring can describe the problem but not contain it. The practical response is to shift control earlier, to issuance and authorisation, rather than relying on post-hoc review.

If agents can obtain and release access inside a single task, traditional certification windows lose much of their value, and control effectiveness depends on policy at the moment of action. That is why organisations should pair agent discovery with runtime privilege constraints and formal offboarding.

For practitioners

• Inventory every agent and automation path Create a register of all AI agents, embedded automations, and delegated workflows, including owners, connected tools, and data access. Unknown or unowned actors should be treated as shadow AI until they are formally approved or removed.
• Bind agent access to short-lived privileges Replace standing access with task-scoped permissions for agents wherever possible, and require explicit revocation after the workflow completes. This reduces the chance that a reused credential turns a single action into broad downstream access.
• Add action-level authorisation to API controls Check not only that an agent can authenticate to an API, but that it is allowed to perform the specific business action in that moment. Pair OAuth, scopes, and policy enforcement with runtime checks for high-risk calls.
• Tie AI governance to ownership and offboarding Assign a business owner, technical owner, and retirement process to each agent before production use. Remove credentials, tool links, and delegated permissions when the agent is retired, repurposed, or no longer reviewed.
• Test monitoring for agent misuse, not just model drift Extend detections beyond output quality to include unusual tool calls, privilege escalation attempts, unexpected resource access, and delegated actions outside approved workflows. These are the signals that identity controls are failing.

Key takeaways

• AI security best practice lists often stop at models, APIs, and monitoring, but the governance gap is the identity and authority of the agent itself.
• When agents can act on behalf of users or systems, standing privilege becomes a direct control weakness, not just a hygiene issue.
• The practical fix is to combine discovery, task-scoped authorisation, and offboarding so non-human actors are governed with the same discipline as privileged access.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• 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.
• Resource-Level Authorisation: A control pattern where each application or service decides whether a subject should be allowed to act. The decision is based on identity, context, and policy rather than on network location. This is the practical mechanism that makes zero trust enforceable in real environments.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and agentic AI identity alongside workload identity and secrets management. It helps security and IAM practitioners translate identity principles into controls for non-human actors.