Kong Custom Entities are user-defined objects stored in Kong for organizing and exposing application data through the platform. In identity and API governance, they let teams model non-human identities, policies, or metadata as structured records that can be validated, queried, and tied to access workflows, automation, and control enforcement.
What Kong Custom Entities Do
Kong Custom Entities extend Kong with structured records that you define for your own operational model. They are useful when application metadata, policy attributes, or non-human identity context needs to be stored, queried, and reused consistently inside the platform.
Because the objects are first-class data rather than ad hoc labels, they give teams a controlled way to represent relationships between systems, permissions, workflows, and governance decisions. That makes them more durable than spreadsheets or one-off configuration fields when the same information must drive automation repeatedly.
Why They Matter for Identity and API Governance
In identity and API governance, custom entities are valuable because they let you represent the business logic around access, ownership, and control in a machine-readable form. A team can model non-human identities, application metadata, approval states, or policy exceptions in a way that downstream processes can consume consistently.
This matters when policy enforcement depends on more than a single credential check. For example, access workflows may need to look at environment, service class, application owner, or entitlement status before allowing a request to proceed. Custom entities give those decisions a place to live inside the platform instead of scattering them across code and configuration.
How They Support Validation and Automation
Custom entities are most useful when their structure is tightly defined. Validation rules help ensure the data is complete and predictable, which reduces the chance that automation breaks because a required field is missing or a record is shaped differently than expected.
Once stored, the records can be queried by tooling, policies, or integrations. That makes them a practical bridge between governance logic and runtime enforcement, especially when identity-related decisions need to be made at the same point where APIs are exposed or controlled.
In practice, this means the entity schema becomes part of the control surface. If the schema is too loose, teams may create inconsistent records that weaken reporting and enforcement. If it is too rigid, the platform may become hard to adapt as governance needs evolve.
Design and Operational Considerations
Good use of custom entities starts with clear ownership of the data model. Each field should exist for a reason the platform can actually enforce or consume, rather than simply mirroring a general database design. The more directly the schema maps to policy or workflow, the easier it is to maintain over time.
It also helps to treat custom entities as governed configuration, not just storage. That means defining who can create, modify, and read them, and understanding which workflows depend on them before they are used in production. When the data becomes part of access decisions, a weak update process can become a control weakness.
For teams building identity-aware integrations, the real value is consistency. A well-designed custom entity model can become the stable source of truth for ownership, approval state, service metadata, and other operational attributes that need to follow the object across systems.
Risk and Threat Considerations
Custom entities become risky when they are used to drive policy but are not tightly governed. Bad data, stale records, or overly broad write access can distort enforcement decisions, create shadow exceptions, or let an attacker influence how the platform interprets a workflow or entitlement.
Failure mechanism: If the stored record is inaccurate, incomplete, or tampered with, downstream automation may make the wrong authorization, routing, or governance decision. If those records are used to represent non-human identity or access metadata, the control failure can propagate across multiple services.
Impact: The result can be unauthorized access, broken approvals, policy drift, or loss of trust in the platform’s governance logic. In the worst case, a compromised or malformed entity becomes a persistence point for incorrect control decisions.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Custom entities track governed platform objects and their attributes. |
| AC-6 — Least Privilege | Custom entities can influence who may act on stored governance data and workflows. | |
| AU-2 — Event Logging | Entity changes can materially affect access and automation decisions. | |
| Recommendation — Maintain an accurate inventory of managed objects represented by custom entities. Restrict create, update, and approval rights to the minimum necessary roles. Log create, update, and delete activity for governed entity records. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Entity-backed workflows can expose administrative actions if authorization is weak. |
| Recommendation — Enforce function-level authorization on every entity management action. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The term is used for identity and access governance data that supports access control decisions. |
| Recommendation — Bind entity lifecycle and access rules to controlled identity and authorization processes. | ||
Practitioner Guidance
Governance implication: Treat custom entities as part of the control plane, not just application data. Define a clear owner for the schema, restrict who can mutate records, and review whether every field has a direct operational purpose.
What to watch for: Watch for entity sprawl, overlapping schemas, and records that exist only to support a one-off workflow. Those patterns usually signal that the model is becoming harder to validate, harder to audit, and easier to misuse.
Related resources from NHI Mgmt Group
- What is the difference between Kong Custom Entities and standard Kubernetes CRD references in an ingress controller?
- Why do custom Kong plugins need strict validation, timeouts, and non-blocking logic?
- What do teams get wrong when testing Kong custom plugins?
- What do teams get wrong when they manage plugin-specific custom entities only through a database-backed workflow?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org