Insomnia 12.6 tightens Git-native API testing for teams

At a glance

What this is: Kong's Insomnia 12.6 brings Git-native workspace handling, dynamic cloud mocking, and stronger user cleanup controls for API teams.

Why it matters: For IAM and security practitioners, the release is a reminder that developer tooling increasingly touches identity governance, workflow integrity, and unmanaged access cleanup.

👉 Read Kong's product release on Insomnia 12.6 and Git-native API testing

Context

API testing tools have become part of the governance surface, not just developer convenience. When workspace state, mock responses, and user cleanup sit inside the same toolchain, teams need to think about access, change control, and accountability in the same way they would for any other operational system. In this case, the primary keyword is API testing, but the governance question is whether those workflows remain auditable as they move between app, terminal, and shared repositories.

Insomnia 12.6 is built around a familiar enterprise problem: teams already use Git, CI/CD, and identity providers to control software delivery, but their API tooling often sits outside that discipline. Kong's changes bring API workspace files closer to normal versioned development, while the unmanaged-user export feature points to a separate administrative need, namely reconciliation against an identity source of truth. That combination makes the post relevant to NHI, IAM, and lifecycle governance, even though the article is framed as a product release.

Key questions

Q: How should teams govern API testing tools that store workspace files in Git?

A: Treat the workspace as a governed software asset. Apply branch protection, peer review, least-privilege repository access, and commit traceability so API definitions, environment files, and shared collections cannot change without accountability. That approach preserves developer flexibility while keeping change control inside normal engineering and security processes.

Q: Why do unmanaged users in developer tools create IAM risk?

A: Unmanaged users create IAM risk because they sit outside the source of truth that governs joiner, mover, and leaver processes. If they are not reconciled back to the directory, they can retain access after ownership changes, billing cleanup, or offboarding events. Exporting them is useful only if the result feeds access review and removal.

Q: What breaks when mock servers can evaluate responses at request time?

A: What breaks is the assumption that test infrastructure is static and low risk. Request-time evaluation means the mock can process input, alter output, and generate context-specific data, which increases the need for code review, change control, and secret handling around the mock configuration itself.

Q: Who should own API workspace cleanup when local and cloud state diverge?

A: Ownership should sit with the team that controls the workspace lifecycle, usually platform engineering or the API programme owner, with IAM or security involved when access records and identity state diverge. The key is to define who can delete, who can restore, and which state is authoritative when sync drift appears.

How it works in practice

Native Git CLI support for API workspaces

Insomnia 12.6 stores workspace content in a file format that can be manipulated directly with standard Git commands. That means changes made in the terminal or editor sync back into Insomnia in real time, while changes in the app appear in local files and Git diff output. The important technical shift is not simply version control, but shared state: the API definition now behaves like code, with branch, commit, and merge semantics applied to collections and specifications.

Practical implication: treat API workspace paths like governed source assets and apply the same branch, review, and commit controls you use for application code.

Dynamic mocking in cloud-hosted mock servers

Dynamic mocking evaluates response content at request time instead of returning a fixed payload. That allows a mock server to read input, vary output, and generate data such as IDs or emails based on the request context. Moving that capability from self-hosted mock servers into cloud-hosted ones matters because the execution location changes, but the core behaviour does not: the mock now acts more like a programmable test surface than a static stub.

Practical implication: validate who can alter mock logic and where mock data is stored, because test infrastructure can expose the same sensitive context as live services.

Unmanaged-user export and project deletion controls

The admin features address a different class of control gap. Exporting unmanaged users as CSV creates a reconciliation artifact that can be compared against an identity provider or license inventory. The deletion controls then let administrators remove local state or wipe a project with more precision, which matters when synchronized cloud data drifts away from the current operational record. These are lifecycle and governance functions, not just usability improvements.

Practical implication: fold unmanaged-user exports into access review and cleanup workflows so dormant accounts and stale project data do not persist outside identity governance.

NHI Mgmt Group analysis

API tooling is now part of identity governance, not just developer ergonomics. When API workspaces live in Git and mock servers execute request-time logic, the control boundary moves closer to the software supply chain. That means access to collections, mocks, and repo state can affect what gets tested, shared, and shipped. The implication is that API platforms should be governed like operational systems with identity, change, and audit requirements attached.

Unmanaged-user cleanup is an identity lifecycle problem hiding inside a developer tool. The CSV export feature shows that there is enough account sprawl in API tooling to justify reconciliation against an identity source of truth. That is the same lifecycle question IAM teams already face with SaaS shadow accounts and orphaned service access, only here it sits inside a developer workflow. Practitioners should treat this as evidence that governance debt accumulates wherever users can exist outside the primary directory.

Git-native workflows strengthen traceability, but they do not remove governance responsibility. Moving edits into files, diffs, branches, and pull requests improves visibility, yet it also increases the importance of who can change the workspace and when. The real value is not that Git is added to API testing, but that the tool can now inherit mature change-control practices. Practitioners should see this as an opportunity to align API testing with standard engineering controls, not as a substitute for them.

Dynamic mocking expands the attack surface of test infrastructure in the same way modern pipelines expand the blast radius of misconfigurations. A mock that evaluates logic at request time can be useful for realism, but it also becomes a governed execution surface. The named concept here is workflow-state drift: when the state used for testing, collaboration, and admin cleanup no longer matches the current identity and repository record. That drift is what security and platform teams need to manage across API environments.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For the lifecycle side of this problem, see NHI Lifecycle Management Guide for how to keep access, ownership, and offboarding aligned as systems and teams change.

What this signals

Workflow-state drift: API tools that blend local files, Git history, and cloud-hosted execution need the same governance discipline as source code. The practical signal for teams is whether workspace changes can be traced, reviewed, and reversed without relying on tribal knowledge or manual cleanup.

As developer platforms absorb more identity-adjacent features, unmanaged accounts and stale projects become lifecycle events rather than housekeeping tasks. That is where directory reconciliation, change approvals, and deletion policy need to meet in one operating model, not three disconnected ones.

With 80% of organisations reporting AI agents acting beyond intended scope, the broader lesson is that tools which can execute, sync, or shape behaviour at runtime must be governed as active identity surfaces, not static utilities.

For practitioners

• Map API workspaces to source-control controls Treat Insomnia project files as governed repository assets, with branch protection, review requirements, and commit traceability for changes that affect shared collections or specs.
• Reconcile unmanaged users against the identity provider Use the CSV export of unmanaged users to compare tooling access with your directory, then remove dormant accounts and correct ownership before they become review blind spots.
• Define approval boundaries for dynamic mock logic Restrict who can edit request-time templates, faker logic, and response shaping rules, especially where mock servers are shared across teams or mirrored into cloud environments.
• Align deletion workflows with data-retention policy Decide whether local project cleanup, shared project deletion, or full remote wipe is the correct action for each lifecycle event, then document the approval path for each.

Key takeaways

• Insomnia 12.6 pushes API testing closer to standard software governance by making Git, workspace files, and terminal workflows operate as one control surface.
• The release also exposes a quieter identity problem: unmanaged users and stale project state are lifecycle issues, not just admin chores.
• Security and platform teams should align API tooling with change control, directory reconciliation, and deletion policy before these workflows become another source of governance drift.

Key terms

• Git-native workflow: A Git-native workflow stores and changes content through ordinary repository files, branches, and commits rather than only through a product interface. In identity governance terms, it increases traceability, but it also means access control, review, and rollback discipline must be applied to the underlying files and repositories.
• Unmanaged user: An unmanaged user is an account that exists in a tool or platform but is not fully governed by the primary identity source or lifecycle process. These accounts can create audit gaps, licensing waste, and revocation blind spots when ownership or employment status changes.
• Dynamic mocking: Dynamic mocking is a test pattern where a mock server evaluates request context and shapes its response at runtime instead of returning a fixed payload. It improves realism for API testing, but it also creates a live configuration surface that needs review, access control, and change tracking.
• Workflow-state drift: Workflow-state drift occurs when the state used by a tool, repository, or mock environment no longer matches the current authoritative identity or configuration record. It leads to stale access, inconsistent test results, and cleanup errors unless teams reconcile state back to a trusted source.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Kong: Insomnia 12.6 and its Git-native API testing updates. Read the original.