TL;DR: Developers can now test against live gateway configuration instead of stale imported specs because Insomnia 13 connects Insomnia directly to Kong Konnect, according to Kong, while custom linting now enforces API standards automatically. That shifts API governance from manual coordination to versioned, policy-backed execution, which is especially important as agentic AI starts consuming the same API context.
At a glance
What this is: Kong’s Insomnia 13 release ties API testing to Kong Konnect so developers can validate against current gateway truth, with onboarding and custom linting updates rounding out the workflow change.
Why it matters: For IAM, platform, and agentic AI teams, this matters because stale API context creates governance drift, broken integrations, and policy gaps across humans and automated consumers alike.
Context
API truth means the governed record of routes, versions, and configurations that downstream teams and tools should trust. In Kong’s framing, the problem is not whether teams have specs, but whether those specs stay aligned with what is actually deployed and approved.
That gap becomes an identity and access issue when developers, platform teams, or AI agents act on outdated API context. If testing, linting, and runtime governance do not share the same source of truth, policy enforcement becomes inconsistent and failures show up only after deployment.
This is fundamentally a workflow governance problem, not just a developer experience upgrade. The article is about closing the distance between API management state and the tools that consume it, which is increasingly relevant as more automation depends on API contracts.
Key questions
Q: How should teams prevent stale API specs from driving test results?
A: Bind API testing to the live control plane so developers validate against the current routes, versions, and configurations instead of exported specs. That removes a common source of drift between documentation and runtime behaviour, and it makes test failures more meaningful because they reflect the actual deployed interface.
Q: Why do outdated API contracts create governance risk?
A: Outdated contracts let teams believe a request is compliant when it is really aligned to an old interface state. That creates policy drift, broken integrations, and inconsistent enforcement across development, testing, and runtime environments, especially when multiple teams or tools rely on the same API.
Q: What do security teams get wrong about API linting?
A: Many teams treat linting as a style preference, but it is actually a policy enforcement control. When rules are embedded in the project and applied consistently, they reduce review dependence and catch non-compliant patterns early. Without that, standards stay aspirational and drift becomes normal.
Q: How should organisations govern external tools used by AI agents?
A: Organisations should review external tools as security inputs, not convenience features. Each tool needs ownership, approval, metadata inspection, and ongoing monitoring for hidden instructions or unexpected behaviour. If an AI agent can act on a tool, then the tool’s provenance and control status should be governed like any other sensitive integration.
How it works in practice
Live gateway configuration as the test source of truth
Insomnia 13 connects directly to Kong Konnect so the client can pull routes, endpoints, versions, and configurations from the governed control plane rather than a copied spec. That matters because imported OpenAPI files often lag behind runtime state, and the resulting mismatch creates false confidence in test results. When the test client and the gateway share the same authoritative configuration, the test reflects deployed reality instead of an approximation. This reduces drift between design-time documentation and operational truth.
Practical implication: teams should treat the control plane as the authoritative source for test context, not static spec exports.
Custom linting turns API standards into enforcement
Custom linting in Insomnia 13 means teams can codify API conventions and have them applied automatically in the client workflow. That shifts standards from a social agreement to a machine-enforced rule set, which is especially useful when multiple developers or teams touch the same API surface. Linting is not the same as policy enforcement at the gateway, but it closes an important gap by catching violations before code review or release. In governance terms, it reduces reliance on memory and informal coordination.
Practical implication: define API rules once and apply them consistently across cloud projects, local testing, and shared workflows.
Why stale API context becomes riskier with agentic AI
The article’s agentic AI point is important because AI systems can consume API context faster and more literally than humans do. If an agent is given a stale spec, it may call deprecated endpoints, send outdated parameters, or repeat failures in ways that are hard to trace back to the source. The issue is not that the agent is autonomous here, but that it amplifies the consequences of outdated interface truth. In practice, API governance has to account for both human developers and machine consumers using the same contract.
Practical implication: align agent-facing API context with the same live configuration that human teams test against.
NHI Mgmt Group analysis
API truth is becoming the control plane for both developers and AI consumers: The core governance issue is no longer whether an API exists in documentation, but whether every consumer is operating from the same versioned reality. When test tools, policy rules, and runtime configuration diverge, organisations create an identity-adjacent trust gap around what is authorised, current, and safe to call. The practitioner takeaway is to treat API context as governed infrastructure, not static documentation.
Stale specifications create policy drift even when teams believe governance is in place: A copied spec can satisfy process while still misrepresenting the deployed interface. That is a classic source of false assurance because the governance control appears present, but it is anchored to outdated state. The practitioner implication is to re-evaluate any workflow that depends on exported artefacts rather than live configuration.
Custom linting is a governance control, not just a developer convenience: The most valuable part of client-side enforcement is that it moves standards earlier in the lifecycle, before nonconforming requests reach review or release. That matters because many API failures start as small contract deviations that are easy to miss in manual checks. Teams should view linting as part of API policy execution, not merely code-style hygiene.
Named concept: API truth gap: This is the distance between the governed API state and the state used by developers, testing tools, or AI consumers. The gap matters because every extra copy of the contract increases the chance that policy, testing, and runtime drift apart. Practitioners should collapse that gap wherever possible by binding tools to live gateway context.
Agentic AI increases the cost of API governance mistakes: Even when an AI system is not autonomous, it can still operationalise bad context at machine speed. Outdated routes, stale parameters, and inconsistent policy signals become debugging and security problems at the same time. The lesson for identity and access teams is that API governance now needs to hold up under both human interpretation and machine execution.
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Read next: NHI Authentication Guide
What this signals
API truth gap: The more often teams export, copy, and re-import API definitions, the more likely governance will drift away from runtime reality. Binding test tools to the live control plane reduces that drift and makes policy checks meaningful before release.
As AI agents become regular API consumers, stale context stops being a developer nuisance and becomes a control failure. Governance has to ensure the same versioned API truth is what humans test, what linting checks, and what automated consumers execute against.
For practitioners
- Bind API testing to the live control plane Connect development and testing workflows to the authoritative gateway or API management system so requests validate against current routes, versions, and configurations rather than copied files.
- Replace manual API standards checks with linting rules Define reusable linting rules for request structure, naming, and contract conventions so violations are caught automatically before review or release.
- Reduce spec-copy workflows across teams Stop relying on exported specs as the coordination mechanism between platform, development, and testing teams when the source system already contains the authoritative API state.
- Align agent-facing API context with runtime truth If AI tools or assistants consume API context, make sure they read from the same governed source as human developers so they do not act on stale endpoints or parameters.
- Treat onboarding as part of governance Use the redesigned first-run experience to get new contributors into the governed workflow quickly so they start from the current source of truth instead of shadow copies.
Key takeaways
- The article is really about API governance drift, not just a testing feature update, because live configuration and copied specs can diverge quickly.
- Insomnia 13 reduces that drift by tying test workflows to Kong Konnect and by turning API standards into automatic linting checks.
- The practical lesson is to make the governed control plane the source of truth for both human developers and machine consumers.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article centers on keeping API truth aligned with the governed inventory and current configuration. |
| API10 — Unsafe Consumption of APIs | Stale specs and copied context can make clients consume APIs unsafely or incorrectly. | |
| Recommendation — Use API inventory controls to keep test tools aligned with the authoritative API state. Validate API consumers against live contracts before they rely on the interface. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Governed API context determines what can be called and under what authorisation model. |
| Recommendation — Align API authorisation checks with the current governed interface and not with stale exports. | ||
| MITRE ATT&CK | TA0006;TA0007 — Credential Access; Discovery | The risk pattern includes discovery of outdated API routes and misuse of stale access context. |
| Recommendation — Map stale API context to discovery and credential-use workflows in detection and control reviews. | ||
Key terms
- API truth: API truth is the reliable, current understanding of what an application programming interface actually does, accepts, and returns. It combines documented behavior, observed responses, authentication rules, error patterns, and data contracts so teams can trust integrations, detect drift, and govern machine-to-machine access with accuracy.
- Shared control plane: A shared control plane is a central layer that connects policy, risk, privacy, and security workflows so teams work from the same source of truth. It reduces duplicated reviews and improves auditability when multiple groups must govern the same AI system.
- API Linting: API linting is the automated checking of an API description for syntax errors, schema mistakes, and rule violations. It helps teams catch invalid types, undefined references, and inconsistent structure before those problems spread into documentation or test workflows. Linting improves review speed and reduces avoidable rework.
- Agentic AI API context: Agentic AI API context is the contract, route, and parameter information an AI system uses when it interacts with APIs. Even when the system is not fully autonomous, stale context can cause repeated failures, deprecated calls, and hard-to-trace governance drift.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org