A custom endpoint is a gateway-managed way to expose an external HTTPS API through a standard proxy path. It lets organisations attach access control, credential handling, and request logging to a third-party service, so the service behaves like part of the governed AI stack rather than a separate integration.
Expanded Definition
A custom endpoint is not just a convenience route. In NHI and agentic AI environments, it is a governed proxy path that sits between an AI system or internal application and an external HTTPS API, allowing the organisation to enforce identity-aware controls before traffic reaches the vendor service. This makes the endpoint part of the security boundary rather than a loose integration point.
Definitions vary across vendors, because some platforms use the term for request routing alone while others include credential injection, policy enforcement, and logging. For NHI management, the more precise meaning is a controlled exposure mechanism for secrets, tokens, and API calls, often paired with NIST Cybersecurity Framework 2.0 principles for access control, monitoring, and recovery. It is especially relevant when an agent needs external tools but should not hold raw credentials directly.
The most common misapplication is treating a custom endpoint as simple URL masking, which occurs when teams publish a proxy path without enforcing authentication, logging, or credential lifecycle controls.
Examples and Use Cases
Implementing custom endpoints rigorously often introduces routing and policy complexity, requiring organisations to balance tighter governance against added latency, maintenance, and troubleshooting overhead.
- An AI coding assistant calls a ticketing API through a proxy endpoint that injects a short-lived token and records every request for audit review.
- A procurement workflow uses a custom endpoint to reach a supplier portal while keeping the supplier credential in a managed secret store rather than in the application code.
- An operations agent accesses a cloud monitoring API through a standard proxy path so access controls, rate limits, and request logs are applied consistently.
- A vendor integration is moved behind a custom endpoint after NHI review identifies direct API exposure and weak credential handling in the original design.
These patterns align with the governance themes in the Ultimate Guide to NHIs, which emphasizes visibility, rotation, and offboarding for service identities. They also fit the access and monitoring expectations reflected in NIST Cybersecurity Framework 2.0 when third-party APIs become operational dependencies.
Why It Matters in NHI Security
Custom endpoints matter because they determine whether an external dependency is treated as governed infrastructure or as an uncontrolled shortcut. If the proxy path is not tied to identity, logging, and secret handling, it can create a blind spot where agents and service accounts reach sensitive APIs without clear ownership or revocation paths. That risk is amplified in environments where NHI sprawl is already high. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
Practitioners should treat custom endpoints as part of the control plane for NHI governance, not as a cosmetic integration layer. When configured well, they support least privilege, traceability, and faster incident response. When configured poorly, they can obscure which agent, service account, or API key actually touched the downstream system. Organisations typically encounter the consequence only after an abuse case, leak, or vendor incident, at which point custom endpoint governance 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 | Custom endpoints govern how non-human identities reach external APIs. |
| NIST CSF 2.0 | PR.AC-4 | Endpoints enforce access rights before an API is reached. |
| NIST Zero Trust (SP 800-207) | A custom endpoint fits Zero Trust by verifying each request path. |
Place every proxy path under NHI inventory, authorization, and logging controls.
Related resources from NHI Mgmt Group
- What is the difference between endpoint compromise and management-plane compromise?
- What is the difference between endpoint malware detection and workload identity governance?
- When should organisations prefer standards over custom implementations?
- What is the difference between endpoint containment and identity containment?
