TL;DR: A developer used one valid credential to reach more than 6,700 DJI robot vacuums across 24 countries because the platform had no object-level boundary, exposing live video, audio, and floor plans, according to Okta; the same API weakness becomes far more dangerous when AI agents inherit those credentials. The core problem is not stolen access but undefined authorisation scope, which turns any legitimate token into system-wide reach.
At a glance
What this is: This is an analysis of broken object-level authorisation in AI agent APIs, using a DJI vacuum exposure example to show how one valid credential can overreach across thousands of devices and why AI agents amplify that boundary failure.
Why it matters: IAM and platform teams need to treat resource-level authorisation as a governance control for human, application, and AI agent access alike, because weak API boundaries can turn legitimate credentials into broad data exposure.
By the numbers:
- The article says one valid credential could reach over 6,700 DJI robot vacuums across 24 countries.
Context
Broken object-level authorisation is the failure to enforce who can access which specific record, device, or resource after authentication succeeds. In this case, the issue was not stolen credentials or malware, but a missing resource-level boundary in the API layer. That matters for AI agent APIs because agents typically act through the same authenticated interfaces as humans and workloads.
The article frames the exposure as a governance problem, not just a technical bug. A valid credential was able to traverse a large device fleet, which means access scope was defined too broadly or not defined at all. For identity programmes, that is a classic entitlement design failure with direct implications for NHI and agentic AI access models.
The same structural weakness becomes more acute when AI agents are introduced, because agents can make repeated API calls at machine speed and across multiple systems. If those calls inherit broad credentials, the authorisation flaw scales from single-object exposure to enterprise-wide blast radius.
Key questions
Q: What breaks when an API only checks whether a caller is authenticated?
A: Resource-level boundaries break. A caller can be successfully authenticated and still gain access to records, devices, or data objects it was never meant to reach. That is the core failure behind broken object-level authorisation: the system proves identity but does not prove entitlement to the specific object being requested.
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: How can security teams tell whether API access is properly scoped?
A: A simple test is whether a valid low-privilege credential can reach another customer’s object, another device, or an adjacent record outside its assigned scope. If that succeeds, the API is enforcing identity but not object-level permission, and the access model is too broad for the data it protects.
Q: Should organisations treat AI agent access to AWS differently from CI/CD access?
A: Yes. CI/CD access is usually job-bound and repeatable, while AI agent access can be more context-sensitive and less deterministic at runtime. Both should be ephemeral, but agent sessions need tighter scoping, explicit approval boundaries, and stronger attribution because the workflow can change while it is running.
Technical breakdown
Why broken object-level authorisation happens in API architectures
Broken object-level authorisation occurs when an API verifies that a caller is authenticated but fails to verify that the caller is allowed to access the specific object requested. The result is a valid token or session being accepted as a blanket entitlement rather than a scoped permission. In many enterprise systems, resource IDs are predictable, access checks are inconsistent, or the application trusts the client to request only what it should see. That design breaks as soon as a caller changes an object identifier or reuses one credential across multiple records. AI agent workflows inherit the same flaw when they call the same APIs without a resource-level policy gate.
Practical implication: Enforce object-level checks at the API boundary, not in the client or workflow layer.
Why AI agents magnify resource-level boundary failures
AI agents do not create the authorisation problem, but they magnify it because they can issue many API calls quickly, follow branching task paths, and reuse the same delegated credential across tools. When an agent’s credential is not constrained to a task, tenant, or object set, a single prompt or misrouted action can fan out into broad access. This is especially risky where delegation chains accumulate permissions or where the agent uses service credentials that were built for human-paced workflows. The control gap is not the model; it is the missing scope enforcement around the identity the agent uses.
Practical implication: Scope agent credentials to the minimum resource set and task boundary they actually need.
What resource-level authorisation means for live data exposure
Resource-level authorisation is the difference between being authenticated and being allowed to see a specific camera feed, audio stream, or floor-plan record. In the DJI example, the credential itself was legitimate, but the platform failed to constrain what that credential could reach. That pattern shows why object-level controls matter for customer data, operational telemetry, and internal SaaS workflows alike. Once a credential can enumerate or access arbitrary objects, the organisation has effectively removed segmentation from the application layer. For identity architects, the question is not whether login works, but whether every object has an access rule attached to it.
Practical implication: Model every sensitive object with an explicit access rule and test that rule with a valid but low-privilege credential.
Threat narrative
Attacker objective: The objective is to turn one valid credential into broad access to sensitive object data across a platform or device fleet.
- Entry occurred through a legitimate credential used in the normal application flow, not through stolen passwords or malware.
- The credential was then able to access object data outside its intended boundary because the API did not enforce resource-level authorisation.
- Impact followed when live camera feeds, microphone audio, and floor plans became reachable across thousands of devices and homes.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Broken object-level authorisation is a boundary failure, not an authentication failure. The credential in this case was valid, which means login succeeded exactly as designed. The failure was that the system treated authentication as permission to traverse objects, tenants, or devices without a second, resource-specific decision. That distinction matters because many identity programmes overinvest in proofing and underinvest in object-level enforcement.
AI agents inherit the same API boundary assumptions as the applications they call. If an agent is given a broad credential, it does not need to steal anything to create exposure. The agent can simply follow its workflow into data that the platform never fenced off, which means agentic risk here is an authorisation design problem first and an AI problem second. Practitioners should treat agent credentials as a stress test for API scoping discipline.
Identity governance has to move from who can log in to what each credential can touch. A valid token that can reach arbitrary objects collapses the separation between account access and data access. That collapse is especially dangerous for NHIs and AI agent integrations, where one credential may serve many calls and many systems. The practical implication is that entitlement design now has to be object-aware, not just account-aware.
Resource-level authorisation is the named control gap this article exposes. The platform had authentication, but it lacked a durable fence between one customer’s object set and another’s. That gap is exactly where modern IAM, API security, and NHI governance intersect, because service credentials and agent credentials are only as safe as the objects they are prevented from reaching. Practitioners should read this as a reminder that broad validity is not the same as safe use.
Delegation chains do not excuse weak scope definitions. The article shows how a credential used through AI tools can inherit the same overbroad reach as any other caller. Once a delegation chain can pass access without narrowing it, the system is optimizing for convenience at the expense of containment. The implication is that governance must break the assumption that trusted callers are automatically trusted for every object they can name.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: NHI Authentication Guide
What this signals
Object-level authorisation is now a governance control, not just an API issue. Teams that still think of it as a developer defect will miss the larger pattern: one valid credential can become broad object reach when entitlements are not bound to specific resources. That is why identity, application security, and platform engineering now need a shared scope model.
AI agent access should be designed as constrained delegation, not reusable login. The identity used by an agent must be narrower than the identity used by a human operator, because agents amplify every scope mistake through speed and repetition. When an agent can traverse objects freely, the organisation has already lost the containment layer that would have made a breach smaller.
For practitioners
- Enforce object-level checks at the API layer Require every read and write request to pass a server-side authorisation decision tied to the specific resource ID, tenant, and action, not just the session or API key.
- Scope AI agent credentials to task-bound objects Issue agent credentials that can only reach the records, devices, or workflows explicitly needed for the current task, and deny cross-object enumeration by default.
- Test valid-credential overreach paths Use a low-privilege but legitimate credential to verify whether it can reach other customers’ objects, hidden endpoints, or adjacent records that should be out of scope.
- Treat delegation as a scope-reduction event When an agent passes work to another process, narrow the downstream permissions rather than inheriting the upstream token unchanged.
Key takeaways
- A valid credential can still be unsafe if the API does not enforce object-level boundaries.
- The DJI example shows how one missing resource fence can expose thousands of devices, not just one.
- AI agents intensify the same failure, so scoped delegation and server-side authorization are now baseline requirements.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The article centers on object-level access failure in an API. |
| Recommendation — Enforce object-level authorization on every API request and verify resource scope server-side. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | The article shows a human and AI workflow using credentials that can overreach across objects. |
| NHI-05 — Overprivileged NHI | The credential reached far more objects than the task required, which is classic overprivilege. | |
| Recommendation — Restrict reusable credentials so they cannot be used as broad access shortcuts for other actors. Review NHI scopes against actual object access and remove any unnecessary cross-resource reach. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | A valid credential enabled broad traversal across device objects and data. |
| Recommendation — Map overbroad API access to credential abuse and lateral movement paths in detection and testing. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article shows access that exceeded the minimum needed for the task. |
| Recommendation — Apply least privilege so every credential is limited to the smallest necessary object set. | ||
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.
- 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.
- Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.
- Scope reduction: The process of narrowing an identity’s permissions to the smallest set needed for the workflow to function. For machine and agent identities, scope reduction is best validated through sandbox testing, because stated requirements often exceed actual operational need.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org