Treat it as both, but with identity governance at the centre. AppSec covers testing and vulnerability management, while IAM controls who or what can call an API, under what scope and for how long. In modern environments, especially AI-enabled ones, separating those responsibilities leaves an accountability gap that attackers can exploit.
Should API security sit under IAM, AppSec, or both?
api security belongs to both disciplines, but the centre of gravity depends on the control in question. AppSec owns how the API is built, tested, and hardened; IAM owns who or what can call it, what scopes they get, how long access lasts, and how delegation is governed. Treating one side as sufficient creates blind spots in both prevention and accountability.
An API can be technically well tested and still be unsafe if the caller is overprivileged, the token is too broad, or authentication is weak. Likewise, an API can have strong identity controls and still be exposed through broken object-level checks, injection, or insecure business logic. That is why the right mental model is shared ownership with clear control boundaries, not a forced choice between teams.
For readers mapping this to implementation, the useful distinction is between OWASP API Security Top 10 issues such as broken authorisation and API abuse, and the access decisions that govern callers, tokens, and scopes. In practice, security teams need both the application failure modes and the identity layer that limits blast radius when a credential or client is compromised.
Where AppSec ends and IAM begins for APIs
AppSec should own the security properties of the API itself: input validation, output handling, object and function authorisation checks, secure transport, error handling, and test coverage for abuse cases. Those controls answer whether the API behaves safely when it receives unexpected or hostile requests. They are about the integrity of the interface.
IAM should own the calling identity and its authority: API clients, service principals, OAuth apps, machine identities, token issuance, scopes, rotation, expiry, and revocation. That layer answers whether the caller should be trusted at all, and if so, what it is allowed to do. For machine-to-machine APIs, identity becomes the policy boundary that determines whether a request is legitimate before the application code even evaluates the operation.
The practical handoff is simple. AppSec validates the endpoint behaviour, while IAM validates the caller’s proof and privilege. If either side is weak, the API can fail securely in theory but fail open in reality. Teams that blur this line often end up testing for vulnerabilities without governing access, or governing access without testing the abuse paths that identity controls cannot stop.
Where APIs are exposed to external callers or automation, the IAM side is especially visible in token design and credential hygiene. A disciplined implementation uses OWASP ASVS for authentication, session, and access-control expectations, then pairs that with API-specific authorisation checks and short-lived credentials that are scoped to the minimum viable action.
Why the split matters more in AI-enabled systems
AI-enabled environments often increase the number of non-human callers, delegated actions, and chained services behind an API. That makes identity governance more important, not less, because an autonomous workflow can inherit privileges, reuse tokens, or call tools faster than a human reviewer can intervene. In those settings, the question is no longer only whether the API is secure, but whether the calling identity is bounded enough to keep an automated error from becoming a systemic incident.
This is also where accountability gaps appear. If AppSec assumes IAM is managing scope, and IAM assumes AppSec is validating the endpoint, neither team may own the full path from authentication to business action. Attackers look for exactly that gap, because a valid token with excessive privilege can be as useful as a code flaw. The result is often quiet abuse rather than dramatic exploitation, which makes ownership clarity part of the control itself.
For cloud and machine-to-machine patterns, the strongest reference point is a model of scoped, temporary, and revocable access. A good starting point is API Key Management Guide, which reinforces that access material must be scoping, rotation, and revocation aware rather than treated as a permanent integration shortcut.
Risk and Threat Considerations
When API security is split too loosely between IAM and AppSec, the main risk is control gap exploitation. An attacker does not need to break every layer, only the one that is weakest, such as an overbroad token, a missing object-level check, or a reused secret that still authenticates successfully.
Failure mechanism: The identity layer grants a caller more authority than the API logic can safely assume, or the API logic accepts requests that identity controls did not intend to permit. That mismatch can lead to data exposure, unauthorized actions, privilege escalation, or silent misuse of automation at scale.
Impact: The blast radius is usually larger than teams expect because the same identity pattern is often reused across services, environments, or agents. A single weak API trust path can therefore create repeated abuse, not a one-off defect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | API authorisation failures are central to deciding whether IAM or AppSec owns API risk. |
| Recommendation — Test object-level access checks on every API before shipping. | ||
| OWASP ASVS | V6 — Authentication | API caller identity and token handling are core to the IAM side of API security. |
| V8 — Authorization | API access scope and caller permissions determine what IAM must govern. | |
| Recommendation — Verify authentication strength for every API client and token flow. Enforce authorization checks on every sensitive API action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys and tokens need lifecycle controls for issuance, rotation, and revocation. |
| AC-3 — Access Enforcement | API requests must be limited by enforced permissions, not just authenticated. | |
| Recommendation — Manage API authenticators with rotation, storage, and revocation controls. Enforce least-privilege access decisions on API operations. | ||
Practitioner Guidance
What to prioritise: Decide which team owns authentication, token/scopes, and caller governance, then define which API checks belong to AppSec so nothing falls between the cracks. The ownership model should be visible in design reviews, not only in incident response.
What to verify: Confirm that every sensitive API has a caller identity, a narrow scope model, expiry or rotation for its credentials, and an application-level authorisation check for the operation itself. If any one of those is missing, the control stack is incomplete.
Common mistake: Treating API keys or OAuth tokens as a substitute for secure API design. Authentication only proves who is calling; it does not prove the caller should be allowed to perform the specific action.
Practitioner takeaway: The safest model is shared ownership with explicit boundaries: IAM governs caller authority, AppSec governs request safety, and neither should assume the other has closed the loop.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- Should healthcare IAM teams treat AI authorization as part of HIPAA compliance or general security?
- Should IAM teams treat appsec root causes as part of their own programme?
- Should IAM teams treat API testing as part of governance or development?