Put governance in the place where developers already create and change API artefacts, because controls that live elsewhere tend to be bypassed. The right decision is the one that reduces duplicate state, preserves version integrity, and keeps permissions visible at the point of work. That usually means embedding governance into the workflow rather than adding another review surface.
Where API governance belongs in the delivery workflow
API governance is strongest when it sits where the API is already being defined, reviewed, and changed. If developers must leave their normal workflow to satisfy governance, they will often treat it as a separate compliance activity and bypass it. That creates duplicate state, inconsistent rules, and a weak link between the approved API design and the running implementation.
The practical question is not whether a testing tool can enforce some governance rules, but whether it is the best system of record for those rules. A testing surface is valuable for validation, but governance decisions usually need to be visible earlier, closer to versioned artefacts, policy definitions, and ownership. That is the point where drift is easiest to prevent.
In practice, governance belongs in the workflow that already holds the authoritative API artefact, whether that is a repository, platform portal, gateway configuration, or another controlled change path. The more places a policy can be edited, copied, or re-entered, the more likely the organisation is to lose traceability between intent, approval, and deployment.
Why testing tools are usually the wrong system of record
Testing tools are good at finding defects, but governance needs persistence, versioning, and accountability. A testing-only model tends to produce brittle checks that can be ignored, rerun manually, or diverge from the policy that production actually enforces. That is especially risky when permissions, route exposure, request validation, or schema constraints are involved.
Where governance depends on controls around access or API behaviour, the decision surface should stay close to the control surface. For API-specific security risks such as broken authorisation or unsafe exposure of functions, guidance such as the OWASP API Security Top 10 is useful because it reinforces that the security issue is not only whether a test passes, but whether the control is embedded in the place that changes the API.
If governance is stored only in a test harness, two problems appear quickly: first, developers may fix the test rather than the design; second, the real policy can drift from the artefact that ships. A stronger pattern is to treat tests as evidence of enforcement, not as the authoritative location of governance itself.
Designing governance so it survives change
The decision should be anchored in three questions: where is the API artefact created, where is it approved, and where is it deployed. Governance should live where those three steps are naturally connected, because that is where version integrity is preserved. If the answer to any of those steps lives in a different tool, integration should be used to synchronise state rather than duplicating policy logic.
This is why integrated lifecycle and access governance patterns are often a better fit than detached review gates. An IGA Buyer's Guide is relevant here because it frames governance as lifecycle control, reviews, roles, and consistent ownership rather than as a one-off test outcome. Similarly, the AI Security Platform Buyer's Guide is useful as a broader pattern for choosing workflow-integrated controls over disconnected point solutions.
For organisations that already use policy-as-code or gated delivery, the best outcome is usually a single authoritative policy source with automated checks attached to the build, review, or release path. That keeps governance visible without making the testing tool the place where policy truth lives.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | API governance placement affects how function-level access is enforced. |
| API8 — Security Misconfiguration | Split policy state between tools creates inconsistent API security configuration. | |
| Recommendation — Enforce function-level checks in the authoritative API control path, not only in test tooling. Keep a single source of policy truth and sync tests to it. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Governance should control configuration where the API artefact changes, not in a separate checker. |
| Recommendation — Embed configuration governance into the change workflow and validate drift continuously. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The question is about where change approval and governance should reside. |
| AC-6 — Least Privilege | Visible permissions at the point of work reduce bypass risk and excessive access. | |
| Recommendation — Place approval and change control at the authoritative API artefact lifecycle. Limit governance-edit access to the workflow owners who need it. | ||
Practitioner Guidance
What to prioritise: Put the policy where the API changes happen, then use the testing tool to verify compliance against that policy. If the control only exists in a tester, expect drift and workarounds.
What to verify: Confirm that one source owns the rule, one workflow enforces it, and the same versioned artefact is what reviewers, testers, and deployers see. If those are different, the organisation has a governance gap, even if the tests are green.
Common mistake: Teams often add a governance check to a scanner or test suite because it is convenient, then assume that convenience equals control. In reality, convenience at the wrong layer usually creates duplicate state and weak accountability.
Practitioner takeaway: If a governance decision affects what can ship, it belongs as close as possible to the API artefact and change path, with testing used as enforcement evidence rather than the source of truth.
Related resources from NHI Mgmt Group
- How should organisations decide whether DLP belongs with IAM governance?
- How can organisations decide whether an AI agent belongs in PAM, IAM, or NHI governance?
- How should organisations decide whether AI agent access belongs in IAM or separate governance?
- How do organisations decide whether MCP belongs in IAM, PAM, or NHI governance?
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org