API security starts in code, not at the gateway

At a glance

What this is: This is an API security analysis arguing that the highest-risk flaws are introduced in code and the CI/CD pipeline, before gateways or runtime tools ever see them.

Why it matters: It matters because IAM, PAM, and application security teams need to govern authentication, authorization, and secrets at development time, especially as AI-generated code and shadow APIs expand the attack surface.

By the numbers:

• 81% of organisations lack full visibility into how and where AI is used across the SDLC.
• 62% of code generated by the latest LLMs contained at least one exploitable vulnerability.

👉 Read Cycode's analysis of API security across the ADLC

Context

API security fails when teams treat the gateway as the primary control point instead of the codebase. Authentication logic, object-level authorization, OAuth scope decisions, and secrets handling are usually created during development, which means a production-only view misses the real failure point. The problem has grown sharper as AI-generated code now enters the software delivery lifecycle with limited oversight.

That creates a direct governance issue for identity teams as well as application security teams. APIs often carry access tokens, scopes, and service-to-service permissions that function as non-human identities in practice, even when no human user is involved. A program that cannot inventory those identities, review their privileges, and detect hardcoded credentials will keep finding the same flaws after deployment, which is now typical rather than exceptional.

Key questions

Q: How should security teams implement API security in the software delivery lifecycle?

A: They should place controls where the risk is introduced. Use design reviews for auth models and OAuth scopes, SAST and secrets detection during development, SCA at build time, DAST before release, and runtime monitoring in production. That sequence catches code-level flaws before attackers can exploit them and avoids relying on gateways to fix issues that already shipped.

Q: Why do APIs with weak object-level authorization create such a large risk?

A: Because the attack is usually just a parameter change, not a noisy exploit. If the handler does not verify ownership or permission for each object, an attacker can access another user’s data while the request still looks legitimate. That makes the flaw hard to spot in traffic and easy to miss unless code review and static analysis catch it first.

Q: What do security teams get wrong about shadow data?

A: Many teams treat shadow data as a discovery problem when it is also a governance problem. If data is created, duplicated or copied outside normal ownership and classification paths, it cannot be reliably protected or reviewed. The practical response is to treat unclassified data as a signal of control failure.

Q: How can organisations govern AI-generated API code safely?

A: They should apply the same controls to agent-authored code as to human-written code, with no exceptions. That means policy checks on every commit, automated secrets scanning, dependency scanning, and review of generated authentication logic. If AI can create endpoints and scopes faster than humans can inspect them, governance has to become machine-enforced.

Technical breakdown

Why BOLA is a code-level authorization flaw

Broken object level authorization, or BOLA, happens when an API handler returns or modifies an object without checking whether the requester can access that specific object. The exploit is simple because the attacker only changes an identifier, while the request otherwise looks normal. Traffic inspection usually misses it because the malicious call is structurally valid. The real defect sits in the business logic layer, where the object check should have been written but was not. Static analysis can flag missing checks in handler code before deployment, which is why object-level authorization belongs in development review rather than runtime-only monitoring.

Practical implication: enforce object-level authorization checks in code review and SAST gates before APIs reach staging.

How AI-generated code expands shadow APIs and secret exposure

AI coding agents can create endpoints, authentication logic, and integration code at a pace that outstrips manual review. That increases shadow API risk because teams may never catalogue every generated endpoint, and it also increases secret exposure because agents can reproduce hardcoded credential patterns seen in training data. The result is not a new class of vulnerability so much as faster replication of old ones across more surfaces. In ADLC terms, the defect enters during development and build, not after release. Automated SAST, secrets detection, and software composition analysis are the controls that scale to that pace.

Practical implication: make every agent-generated commit pass the same security checks as human-written code.

Why gateway-only API security misses the earliest failure point

Gateways, WAFs, and runtime monitoring are useful, but they see APIs after the design decision has already been made. By then, broken authentication, overly permissive OAuth scopes, and weak input validation are already embedded in the code. That is why API security programs need layered controls across the ADLC: review at design, SAST and secrets detection in development, SCA at build time, DAST before release, and runtime telemetry in production. This sequencing matters because each control addresses a different stage of the lifecycle, and no single layer can compensate for a flaw that was approved earlier.

Practical implication: move API risk ownership upstream and treat runtime controls as a final detection layer, not the primary defence.

NHI Mgmt Group analysis

API security is now an identity governance problem as much as an application security problem. APIs carry authentication decisions, service tokens, and delegated permissions that behave like non-human identities, even when they are embedded in software. If those credentials are created in code and never governed through lifecycle controls, the organisation has an identity problem hiding inside its application stack. Practitioners should treat API authentication and authorization as part of identity governance, not just secure coding.

Shadow APIs create unmanaged non-human identity surfaces. Every undocumented endpoint effectively becomes an unreviewed access path with its own authentication assumptions, secret exposure risks, and monitoring gap. That is a governance failure, not merely an inventory issue, because no one can review or revoke what they do not know exists. Practitioners should make API discovery and owner assignment mandatory before any endpoint is allowed to exchange tokens or expose business data.

AI-generated API code is accelerating governance debt. Cycode’s cited data shows both AI visibility gaps and exploitable AI-generated code at levels that manual review cannot absorb. The named concept here is code-born authorization drift: authorisation rules that start to diverge because endpoints are generated faster than governance can validate them. That drift weakens consistency across OAuth scopes, object checks, and service permissions. Practitioners should require policy enforcement on every commit, including agent-authored changes.

Runtime-only API security is a control mismatch. WAFs and gateways can still stop abuse, but they do not repair broken authorization models, hardcoded credentials, or unsafe dependency choices introduced upstream. This is why the ADLC matters: it aligns controls to the stage where the risk first appears. Practitioners should reframe API security as a lifecycle governance program with runtime detection as the last line, not the centre.

MCP extends the same governance pattern into agentic interfaces. Model Context Protocol exposes tools and data through API-like interfaces, which means authentication, authorization, and inventory problems reappear in a new layer. The identity angle is direct: agent permissions and tool scopes must be governed with the same discipline as service accounts and API tokens. Practitioners should plan now for MCP inventory, access scoping, and prompt-injection-aware review.

What this signals

Code-born authorization drift: as AI-generated endpoints and agent-authored auth logic scale, governance teams need controls that validate access decisions at commit time, not after release. The practical issue is not just code quality, but whether identity policies can keep pace with machine-written interfaces that create new access paths faster than review cycles can close them.

MCP and other tool-exposure layers will widen the same problem unless teams extend identity inventory, secrets governance, and scope review into agent workflows. A developer platform that cannot trace which non-human identity can call which tool will create the same blind spots that shadow APIs already produce in application estates.

For practitioners, the signal is clear: API security has become a lifecycle and identity governance discipline. That means linking code review, secrets management, and delegated access controls to standards such as the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 where they genuinely apply.

For practitioners

• Move authorization checks into code review Require object-level and function-level authorization checks to be validated in pull requests, with SAST rules that flag missing or inconsistent access control before merge.
• Scan every commit for hardcoded secrets Run secrets detection automatically on human and agent-authored changes, then block merges that introduce tokens, API keys, or OAuth client secrets into the repository.
• Inventory shadow APIs before runtime Map undocumented endpoints from code, repositories, and deployment manifests, then assign an owner and review access paths before the endpoint can exchange data or tokens.
• Apply SCA to API dependencies Check framework and client library dependencies during build to prevent vulnerable API components from entering the release pipeline through third-party packages.

Key takeaways

• Most API risk is created before deployment, which makes code-level controls more important than gateway-only inspection.
• AI-generated code is increasing shadow APIs, secrets exposure, and authorization drift faster than manual review can absorb.
• Identity governance now has to cover API scopes, tokens, and service permissions as non-human identities in the software delivery lifecycle.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.

What's in the full article

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

• Full OWASP API Security Top 10 walkthrough with code examples for each risk class
• Implementation guidance for SAST, DAST, SCA, and secrets detection across the ADLC
• MCP security discussion, including how prompt injection changes tool exposure risk
• Practitioner mapping of API security controls to specific development pipeline stages

👉 Cycode's full post covers the OWASP API Security Top 10, ADLC control points, and MCP security considerations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect API tokens, service accounts, and delegated access back to a governable identity model.