Broken object-level authorization in AI agent APIs

At a glance

What this is: A DJI API flaw allowed a single valid credential to access thousands of robot vacuums because object-level authorization was missing.

Why it matters: That pattern matters to IAM and NHI teams because AI agents, service accounts, and delegated tokens can amplify the same boundary failure across far more systems.

By the numbers:

• The source article says a single valid credential could access over 6,700 DJI robot vacuums across 24 countries.
• Broken Object-Level Authorization has ranked #1 in the OWASP API Security Top 10 since 2019.
• 24 countries.

👉 Read Okta's analysis of the DJI API exposure and AI agent risk

Context

Broken object-level authorization is the failure to limit a valid identity to only the records, devices, or resources it should reach. In enterprise API environments, that failure turns authentication into a false comfort because the credential is accepted even when the access boundary is missing. For NHI governance, the same flaw applies to service accounts, API keys, and AI agents that inherit broad tool access without object-level restrictions.

The DJI case illustrates a common structural problem rather than a one-off IoT bug. When a platform treats successful login as sufficient permission, any valid credential can become a discovery mechanism across tenants, devices, or datasets. That is already a governance problem for human users, and it becomes a larger one once AI agents start calling the same APIs at machine speed.

Key questions

Q: How should security teams prevent valid credentials from accessing the wrong API objects?

A: Security teams should enforce object-level authorization on every request, not just on login. The application must check whether the identity is entitled to the specific device, record, or tenant requested. Pair that with least privilege for non-human identities so a valid credential cannot traverse unrelated objects.

Q: Why do AI agents make broken authorization more dangerous?

A: AI agents make broken authorization more dangerous because they can call APIs repeatedly and at machine speed using the same credential scope. If that scope is too broad, the agent can enumerate or retrieve far more data than a human user could before detection. The underlying issue is blast radius, not just identity.

Q: What is the difference between authentication and authorization in NHI systems?

A: Authentication proves the identity of the caller. Authorization decides what that identity may do with a specific resource. In NHI systems, both are required because a valid service account, API key, or agent token can still be unsafe if the application fails to limit access at the object level.

Q: When should organisations treat an API design issue as an identity risk?

A: Organisations should treat an API design issue as an identity risk whenever a valid credential can reach data or devices beyond its intended scope. At that point, the problem is not only application logic. It is also NHI governance, because the credential’s effective privilege is larger than the team intended.

Technical breakdown

Why object-level authorization fails in API architectures

Authentication answers who or what made the request. Object-level authorization answers whether that identity may touch this specific object, device, or record. Many APIs check the first and skip the second, especially when developers assume that a valid session or token implies safe access. The result is Broken Object-Level Authorization, where identifiers in a request become switch points for cross-tenant or cross-resource access. In NHI environments, the same flaw appears when a service account or agent token is allowed to enumerate or retrieve far more than its task requires. This is a design failure, not a login failure.

Practical implication: Enforce resource-scoped authorization checks on every API call, not just at authentication time.

How AI agents amplify broken authorization boundaries

AI agents do not create this problem, but they scale it. An agent uses credentials to call tools, APIs, and internal services repeatedly, often with delegated authority and no human in the loop for each call. If the underlying credential is too broad, the agent can traverse objects, tenants, or workflows far faster than a human could. That makes authorization mistakes more dangerous than static access misconfiguration because the blast radius expands at machine speed. For NHI governance, the key issue is not whether the agent is autonomous, but whether its identity is constrained to the minimum object set needed for the task.

Practical implication: Scope agent credentials to specific resources and tasks, then monitor for enumeration and cross-object access patterns.

Why valid credentials can still produce a breach

A valid credential proves identity, not entitlement. That distinction matters because many incidents are caused by legitimate tokens being accepted by systems that never enforce what the token may do after login. This is why a stolen secret is not the only risk; a correctly issued secret can also expose data if the application boundary is wrong. In NHI terms, secrets, certificates, and workload tokens all inherit the same problem when the application trusts the credential more than the authorization policy. The control gap is usually in the application layer, not the identity provider.

Practical implication: Test whether a valid token can access sibling objects, adjacent tenants, or privileged device functions without rejection.

Threat narrative

Attacker objective: The attacker objective is unauthorized access to other tenants' device data and home surveillance feeds through a valid credential.

1. Entry occurred through a legitimate credential used against an API that lacked a resource boundary.
2. Escalation happened when the same credential could enumerate and access other customers' devices and data objects.
3. Impact was cross-tenant exposure of camera feeds, audio, and floor-plan data without any password theft or malware.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

BROKEN object-level authorization is now an NHI governance problem, not just an API bug. The DJI example shows that a valid credential can be fully legitimate and still be operationally unsafe if the application does not enforce object boundaries. That matters because service accounts and agent tokens are often granted broad API reach by default. Practitioners should treat authorization design as part of identity governance, not a separate application afterthought.

AI agents turn latent authorization flaws into scale events. A human with a mis-scoped token may expose one object at a time, while an agent can traverse hundreds of objects in seconds. The risk is not only access but speed, repetition, and automation of discovery. That means control teams need to evaluate agent permissions at the object level, not just the role level. Practitioners should assume a small authorization gap can become a large blast radius.

Identity blast radius is the right concept for this class of failure. The important question is not whether a credential is valid, but how far it can move once accepted. If one token can reach unrelated tenants, devices, or data classes, the blast radius is already too large. This reframes least privilege for NHI and agentic systems as a boundary-design issue. Practitioners should measure reachable objects, not just issued credentials.

OWASP API guidance and NHI controls now converge on the same point. Resource-level authorization, scoped tokens, and continuous review are no longer separate best practices. They are one control stack for preventing valid identities from becoming cross-resource access paths. The practical takeaway is simple: if the application cannot prove entitlement per object, the identity layer has not finished its job.

Governance must move from credential issuance to access path validation. Many teams can inventory secrets, but far fewer can answer what each credential can actually reach. That gap is where modern NHI exposure hides. Practitioners should redesign review processes around reachable data and device surfaces, then treat any broad object traversal as a finding, not a convenience.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why credential hygiene alone does not close authorization gaps.
• Track the broader exposure pattern in 52 NHI Breaches Analysis to see how credential misuse and boundary failures compound in real incidents.

What this signals

The governance signal is that API authorization failures now behave like identity failures once non-human identities can call those APIs at scale. Organisations that rely on role assignment alone will miss the real control question, which is how far a credential can travel after it authenticates. The practical response is to measure and reduce identity blast radius across service accounts, API keys, and agent tokens.

Identity blast radius: the set of objects, tenants, and actions a credential can reach once accepted. When that set is larger than the task requires, a single compromise or design flaw becomes a multi-system exposure path. Teams should map reachable data and device surfaces, then enforce review rules against that map rather than against abstract role names.

With 44% of developers following security best practices for secrets management, per The State of Secrets in AppSec, many organisations are already operating with uneven credential discipline. That makes tight authorization checks and object-scoped testing even more important, because the control gap is often downstream of code and process inconsistency.

For practitioners

• Implement object-level authorization checks Require the application to validate every request against the specific object, device, or record being accessed. A successful login must never imply blanket access to sibling resources or other tenants.
• Scope AI agent and service account credentials Give each agent or workload only the API methods and resource sets needed for one task. Avoid reusable broad tokens that can enumerate devices, records, or customer data across the platform.
• Test for cross-tenant access paths Run negative tests that try to access adjacent tenants, sibling objects, and privileged functions with a valid token. Confirm that the application rejects those calls before production exposure.
• Monitor for enumeration and bulk access Alert on repeated object traversal, sudden increases in device lookup volume, and broad reads from non-human identities. Those patterns often signal that authorization boundaries are missing or too loose.
• Map reachable assets for each NHI Document which data classes, devices, and workflows each service account, token, or agent can reach. Use that map in access reviews so teams judge blast radius, not just assigned role names.

Key takeaways

• A valid credential can still create a breach when the API fails to enforce object-level authorization.
• AI agents magnify that weakness because they can enumerate and access resources at machine speed.
• The practical fix is to measure and restrict identity blast radius, not just issue fewer secrets.

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.
• Identity Blast Radius: The set of systems, data, tenants, and actions a credential can reach once it is accepted. The larger the reachable surface, the more damage a single NHI compromise or misconfiguration can cause. Security teams should measure blast radius directly instead of assuming role names describe real risk.
• Non-Human Identity: A machine or software identity used by workloads, service accounts, API keys, certificates, bots, or AI agents. These identities act without human presence, which makes lifecycle control, scoped authorization, and monitoring essential. If they are over-privileged, they can move faster and farther than human users.

Deepen your knowledge

Broken object-level authorization and NHI blast-radius control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is mapping API permissions for agents or service accounts, it is a relevant place to start.

This post draws on content published by Okta covering a DJI API exposure that allowed cross-tenant device access. Read the original.