A public endpoint that accepts requests without verifying the caller first. In identity security terms, this is not just a missing login check. It is a broken trust boundary that can invalidate downstream roles, ACLs, and session controls because the system never establishes who is asking.
Expanded Definition
An unauthenticated API path is an endpoint that accepts requests before establishing caller identity. In NHI security, that means the system has no verified principal to bind to policy, logging, rate limits, or downstream trust decisions. The issue is broader than a missing password check. It can create a broken trust boundary where later controls assume identity exists when it never did.
Definitions vary across vendors and platform teams, because some people use the phrase to mean intentionally public endpoints while others mean accidentally exposed internal routes. NHI Management Group treats the term as a security condition, not a design preference: if the path can trigger sensitive reads, writes, token issuance, or privileged workflow steps without authentication, it is part of the attack surface. That distinction matters when mapping the path to NIST Cybersecurity Framework 2.0 protections and identity governance.
The most common misapplication is labeling a route "public" when it still performs authenticated business logic through hidden assumptions, which occurs when developers rely on network location, obscurity, or downstream checks instead of authenticating at the entry point.
Examples and Use Cases
Implementing authentication rigorously at every API boundary can introduce latency, development friction, and more complex client onboarding, requiring organisations to weigh access simplicity against the cost of missed enforcement points.
- A health check endpoint is intentionally open, but it returns only service status and never leaks configuration, tokens, or tenant data.
- An internal webhook route accepts requests from a partner system without validating identity, which becomes risky when that route can trigger account changes or secret rotation.
- A mobile backend exposes a "guest" endpoint for catalog browsing, but the same path also allows write operations if a request bypasses authentication middleware.
- An agentic workflow posts to an API that mints credentials for a service account, and the route is reachable without proving which agent or workload is calling it.
- The exposure is discovered during review against the controls described in Ultimate Guide to NHIs, then validated against the API's intended trust model using NIST Cybersecurity Framework 2.0.
In practice, the term also applies when a supposedly internal endpoint is published through a gateway, test harness, or misrouted environment and begins accepting unauthenticated calls from automation, not just from human users.
Why It Matters in NHI Security
Unauthenticated API paths are dangerous because they remove the first and most important control point for NHI governance: knowing who or what is acting before granting any capability. Once identity is missing at the edge, downstream ACLs, RBAC, session checks, and token-scoped permissions can be bypassed, weakened, or never invoked at all. That is especially consequential for service accounts, workload identities, and AI agents that depend on APIs for secret retrieval, orchestration, and privilege escalation. The NHI Management Group research base shows that Ultimate Guide to NHIs reports 80% of identity breaches involved compromised non-human identities, and 97% of NHIs carry excessive privileges, which makes any open path a fast route to broad impact.
From a governance perspective, this term matters because unauthenticated access often hides inside service-to-service traffic, where teams assume trusted networks are sufficient. That assumption breaks under Zero Trust, where every request must be evaluated explicitly and continuously. Organisations typically encounter the damage only after an exposed route is abused for data exfiltration, token issuance, or automated abuse, at which point unauthenticated API path remediation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Open API paths undermine caller verification and trust-boundary enforcement. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control begin before any request is allowed to act. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires explicit verification for each request, including API calls. |
Require authentication at API entry points before any NHI action, token issue, or privilege check.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
