Three Questions We Asked About AI Governance — And What the Answers Reveal

Over the past few months, we’ve been having the same conversation on repeat with security leaders about AI at fast-moving engineering organizations. Different companies, different tech stacks, same three questions — and, more often than not, the same challenges bubble up in their answers.

Here’s a version of that conversation, questions are common while the responses are aggregated. This is what we learnt about AI governance from these Security leaders.

1. How is your organization managing developer and agent access to AI tools and LLM APIs?

“We lack centralized control over AI access. While we’ve officially approved various IDEs and coding assistants, we have no unified policy to regulate data input, agent permissions, or session auditing. Engineering teams adopted these tools quickly, and the governance framework has to catch up. Instead of dashboards, we real-time enforcement and risk management.”

This is the pattern at company after company. Someone in engineering leadership approved a shortlist of AI tools — reasonably, because developers were already using them and blocking them outright wasn’t realistic. But “approved” quietly became the entire governance model. Nobody defined what data categories those tools can see. Nobody scoped what an agent with shell or API access is actually authorized to do. Nobody’s watching sessions in real time, and nobody can reconstruct one after the fact.

Tool-level approval and policy enforcement get treated as the same decision. They’re not. One is a procurement checkbox; the other is the actual control.

2. What’s your biggest challenge with AI usage today — cost, security, access control, or something else?

“The landscape is evolving fast, causing our priorities to shift frequently—often alternating between cost concerns and security/data integrity. We are particularly worried about RBAC issues leading to accidental exposure of live cluster permissions and environment variables to LLMs. At present, we lack the policy enforcement and visibility needed to block these exposures in real time, nor do we have audit trails to review them afterward. While monitoring costs is necessary, our true focus remains developer productivity; we view AI spend as acceptable provided it correlates with productivity gains.”

We hear a version of this specific scenario often enough that it’s clearly not a one-off mistake — it’s a structural gap. An engineer with legitimate cluster access and an approved AI tool will, sooner or later, paste something into a prompt that shouldn’t leave the terminal. Not out of carelessness. Out of speed. The tool is faster than typing it out by hand, and nothing in the workflow tells them not to.

The part worth sitting with isn’t the exposure itself. It’s the two-sided blind spot: no real-time policy check to catch it going in, and no session-level record to scope it coming out. Cost dashboards can’t see either of those. Neither can a tool-approval list.

3. Who owns AI governance and spend at your organization — engineering, security, IT, or still undefined?

“Ownership of AI governance remains unclear. Our security leader is pushing for strict data handling and access controls, whereas engineering leaders are prioritizing adoption, and productivity. This split in focus means that while security builds the case for oversight, procurement and licensing decisions stay within engineering operations.”

This is the answer that explains the first two. When ownership is split — security caring about exposure, engineering caring about spend and velocity — and nobody has explicitly claimed the middle, the default outcome is that nothing gets built until something breaks. Not because either side is negligent. Because “who owns this” was never actually decided, so the rollout waits on a conversation that keeps not happening.

What this pattern actually tells us

Three questions, three organizations, one shape:

• Approval isn’t governance. A list of sanctioned tools says nothing about what those tools can see or do once they’re in daily use.
• The real risk is data handling, not spending. Security leaders consistently rank exposure — credentials, cluster access, proprietary code landing in a third-party prompt — well above token costs.
• Ownership is the actual bottleneck. Not budget, not tooling availability — the absence of a clear owner for the access-control and audit-trail layer specifically.

That last point matters more than it sounds like it should. Access control, data handling, and session-level audit trails don’t require a cross-functional budget agreement to start. They can be security owned — the spend conversation can run in parallel, on its own schedule, once someone stops waiting for permission to close the gap they already know exists.

Where AIControls fits

This is exactly the layer Nirmata’s AIControls is built for: policy enforcement and session-level audit trails wrapped around the AI tools your engineers already use — coding assistants like Claude Code, Cursor and Codex, MCP-connected agents, and the servers and tools they call — so a live cluster credential landing in a prompt gets caught before it leaves, not discovered after.

You don’t need to rip out approved tools or win a company-wide governance debate to start. You need a policy layer that knows what’s flowing through them, and a record of every session that did.

Questions worth putting in front of your own team

1. If an engineer exposed production credentials through an AI tool tomorrow, would we know before a customer or auditor told us?
2. Do we have a session-level record for any AI tool in use today?
3. Is there a single policy layer governing prompt data across tools, or is enforcement — if it exists at all — real-time, and tool-by-tool?
4. If security owns this rollout, what’s the smallest version we could stand up without waiting on a cross-functional budget decision?
5. If we caught a risky action in progress — not after the fact — is there any way to actually pause it?
6. Do we have a decision making process to decide when automated enforcement will work and when Human-In-The-Loop review is 

Recognize your own organization in these answers? We’re always happy to talk through what closing this gap actually looks like — reach us at info@nirmata.com.