API security fundamentals for human, NHI and agentic access

At a glance

What this is: A broad API security fundamentals article that maps the main risks, controls, and programme practices for protecting API-driven systems.

Why it matters: It matters because IAM, PAM, NHI, and emerging agentic access controls all depend on API enforcement points that are easy to misconfigure and hard to monitor consistently.

👉 Read Kong's full guide to API security fundamentals and strategies

Context

API security is the discipline of controlling who or what can call an interface, what data can be returned, and what actions the backend will accept. In practice, that means authorization, authentication, rate limiting, inventory, monitoring, and lifecycle control must all work together across human users, service accounts, and software consumers.

Kong's article is a general API security primer, but the governance challenge it describes is wider than web application protection. APIs now sit on the trust boundary for machine identity, workload access, and agentic tool use, so weak control at the API layer becomes an identity problem as much as an application problem.

For practitioners, the useful question is not whether APIs need security. It is whether the organisation can prove that every API path has a defined identity, a bounded privilege model, and observable behaviour across production and non-production environments.

Key questions

Q: How should security teams secure APIs used by service accounts and automated workloads?

A: Security teams should treat machine API access as a governed identity path, not a convenience layer. That means binding each workload to a named identity, scoping tokens tightly, enforcing object and function authorization, and logging every request path. The goal is to make machine access auditable, revocable, and distinguishable from human use.

Q: Why do APIs create more identity risk than traditional application logins?

A: APIs expose backend functions directly, so a weak trust decision can affect data, actions, and connected systems in one call path. Unlike a simple login flow, API access often involves tokens, service identities, and delegated permissions. That increases the chance that overbroad scope or missing object checks becomes a systemic governance gap.

Q: What breaks when APIs are not inventoried and monitored properly?

A: Uninventoried APIs become shadow trust surfaces. Teams lose visibility into who can call them, whether they are still needed, and whether their permissions have drifted. Without logging and inventory, security teams cannot prove access legitimacy, investigate abuse, or remove stale paths before attackers or automation discover them.

Q: How do organisations reduce API abuse without slowing delivery too much?

A: The best approach is to standardise policy at the gateway and delegate only narrow, pre-approved access patterns to development teams. Use rate limits, schema validation, and consistent authorization checks so every new API inherits controls by default. That reduces manual review overhead while keeping risky exceptions visible.

Technical breakdown

Broken object level authorization and broken function level authorization

BOLA and BFLA are two of the most common API failures because they separate the caller from the object or function being accessed. BOLA happens when a caller can change an identifier and reach another user's resource. BFLA happens when a caller can invoke an administrative operation without the correct permission check. Both failures show that authentication alone is not enough. The API must enforce authorization at the object and function layer, not just at login or token validation.

Practical implication: map authorization checks to specific objects and functions, not just roles.

How API keys, OAuth 2.0, and OIDC fit into API security

APIs use different identity patterns depending on whether the caller is a person, a service, or another system. OAuth 2.0 and OIDC handle delegated and federated access, while API keys and bearer tokens often secure machine-to-machine calls. The security risk comes from treating these as interchangeable. An API key is not a user identity, and a token without strong audience, expiry, and scope controls can become a standing privilege path. Secure API design requires the identity type, the token type, and the trust boundary to line up.

Practical implication: align token design to the identity type and verify scope, audience, and expiry.

Why logging, inventory, and rate limiting are identity controls

API logging is not just an observability function. It is how teams prove who or what accessed which endpoint, at what volume, and with what outcome. API inventory is equally important because shadow APIs often bypass the same governance that covers known production interfaces. Rate limiting matters because abuse is often visible first as abnormal request volume or repeated failed calls. Together, these controls turn API traffic into governance evidence and help security teams distinguish legitimate machine activity from misuse.

Practical implication: centralise API inventory and logging before expanding automation or agent access.

Threat narrative

Attacker objective: The attacker wants to turn a normal API trust path into broad data access, unauthorized action, or service disruption.

1. Entry begins when an attacker finds an exposed or weakly protected API, such as a forgotten endpoint, a misconfigured token, or an untracked shadow API.
2. Escalation follows when weak authorization, overbroad scopes, or poor object controls let the attacker move from one valid request to broader data or function access.
3. Impact occurs when the attacker exfiltrates data, abuses backend functions, or uses the API path to disrupt service and extend access across connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API security is now identity security at the enforcement layer. The article describes API controls as technical safeguards, but the practical reality is that every API decision is an identity decision. Authorization, token scope, inventory, and monitoring determine whether a person, service, or workload can act within policy. Practitioners should treat the API layer as the place where identity governance becomes operational.

Broken object and function authorization are governance failures, not just coding defects. When a caller can reach another object or privileged function, the issue is usually not one bug but a missing trust boundary. That boundary should exist in policy, token design, and runtime enforcement together. The implication is that API security teams and IAM teams need a shared control model.

Shadow APIs create shadow identity risk. If an endpoint is not inventoried, it is not governed, and if it is not governed, its access model is usually inferred rather than enforced. That is especially dangerous when service accounts or automation can discover and use these paths faster than human review cycles can detect them. Practitioners should assume any untracked API is an unmanaged trust surface.

API monitoring is the difference between access and accountability. Logging request patterns, failures, and unusual volumes turns API use into evidence that can be audited after the fact. Without that evidence, security teams cannot confidently separate legitimate service-to-service traffic from abuse. The practical conclusion is that observability must be designed as a governance control, not bolted on later.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of how agentic access changes governance, see OWASP Agentic AI Top 10 for the control failures most likely to surface next.

What this signals

API control failures will increasingly be evaluated as identity failures. As organisations expose more services to automation and AI-driven clients, gateway policy, token scope, and endpoint inventory become part of the identity programme's operating model. Teams that already link API controls to the NHI Lifecycle Management Guide will be better placed to govern provisioning, review, and offboarding across machine consumers.

Shadow API discovery should be treated as an assurance problem, not just an asset management task. The governance signal is whether the organisation can prove which identities can reach which interfaces, not whether a catalogue exists on paper. For teams building out API governance, the relevant external baseline is the NIST AI Risk Management Framework when automated clients or AI agents are in play.

The next step for mature programmes is to connect API observability to NHI lifecycle evidence so that access, rotation, and revocation are assessed together. That is where identity governance stops being a static control list and starts functioning as a live trust model.

For practitioners

• Enforce authorization at the object and function level Verify that each API endpoint checks the specific object being requested and the function being invoked, not just the caller's login state or broad role assignment.
• Inventory every API, including shadow and deprecated endpoints Maintain a living register of production, staging, and legacy interfaces so unknown paths do not sit outside policy, logging, and review.
• Bind tokens to narrow audiences and short lifetimes Set explicit token audience, scope, and expiry values so stolen credentials cannot be reused across unrelated services or long-lived automation flows.
• Treat logging as an access governance control Capture endpoint, subject, volume, and outcome data so IAM and security teams can reconstruct who accessed what and detect unusual machine behaviour quickly.

Key takeaways

• API security is fundamentally about controlling identity-driven access to backend functions, not just blocking web attacks.
• Authorization gaps, shadow APIs, and weak monitoring create the conditions for data exposure and unauthorized action at scale.
• Practitioners need shared governance across IAM, NHI, and API teams so that every endpoint is inventoried, scoped, and auditable.

Key terms

• Broken Object Level Authorization: A failure where an API lets a caller access an object it should not be allowed to reach. The danger is not the login itself but the missing check on each requested record, file, or resource. In identity terms, the caller has an authenticated path but an unauthorised object boundary.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• Shadow API: An API that exists in production, staging, or another environment without being fully inventoried or governed. Shadow APIs often escape normal access review, logging, and decommissioning workflows. They are risky because untracked interfaces become untracked trust paths for both human and machine identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Kong: What is API Security? Fundamentals & Strategies. Read the original.