Contact
Published: 08 Oct 2026
Author: Jan-Hendrik Telke

You Can Not Lock AI Down, So Learn to Watch It

Why observability, not restriction, is the missing layer in enterprise AI governance

Every company rolling out generative AI hits the same wall sooner or later. Security wants tight permissions: no access to email, no file uploads, no connectors to internal systems, approved models only. The business wants the thing to actually be useful. Both are right, and that is the problem.

This article looks at why tight permissions quietly kill the value of AI, why letting non-technical users loose without constraints is still genuinely dangerous, and why tracing and monitoring AI usage is the most practical way out of the dilemma.

1. The permission dilemma: safe, useless, and ignored

An AI assistant is only as useful as the context it can see and the actions it can take. A chatbot that cannot read your documents, cannot look at the ticket, and cannot touch the spreadsheet is a better search engine at best. The ROI case for AI in the enterprise rests almost entirely on integration: summarising the customer thread, drafting the reply from the contract, reconciling the report against the source system. Every one of those use cases needs permissions that make a security team nervous.

So organisations restrict. And the restriction produces three predictable effects.

ROI stalls. If the sanctioned tool cannot reach the data where the work happens, users do the work manually and the business case never materialises. Pilots look promising in a sandbox and then die in the security review.

Usability collapses. Every approval step, every blocked connector, every „this file type is not allowed“ teaches users that the official tool is the slow path.

Acceptance moves elsewhere. People do not stop using AI because a policy says so. They switch to their personal account. LayerX’s 2025 enterprise report found that 45% of enterprise employees already use generative AI tools, and that 82% of the pastes into those tools come from unmanaged personal accounts, where the company has no visibility at all (The Register).

It is not only individual employees. In a September 2026 EY survey of 202 senior AI decision-makers at large US companies, 98% had formal AI policies, yet 47% said they had circumvented those policies for urgent deployments (Corporate Compliance Insights). When the organisation itself routes around its own rules, the rules are not the control you think they are.

The uncomfortable conclusion: a very restrictive AI policy does not remove risk. It relocates it to places you cannot see. As a recent Forbes Technology Council piece put it, restricting AI may create more risk than it prevents (Forbes).

2. Why unconstrained AI in non-technical hands is genuinely dangerous

None of this means „just open everything up“. The risk is real, and it is highest exactly where adoption is most valuable: with business users who are not engineers.

That is not a comment on anyone’s intelligence. It is a comment on mental models. A developer knows that a prompt is data sent to a third party, that a connector is an API with credentials behind it, and that text in a document can be an instruction to a model. A sales, finance or operations user usually does not, and there is no reason they should have to.

Three failure modes stand out.

Oversharing by accident. The classic case is still Samsung in 2023: within weeks of lifting an internal ban, engineers pasted proprietary source code, chip test sequences and a transcribed internal meeting into ChatGPT to get help with everyday tasks (CIO Dive). Samsung’s response was to ban generative AI again. The data problem has grown since then: according to LayerX, 22% of pastes and 40% of file uploads into generative AI tools contain personal or payment data (The Register). Nobody was being malicious. They were being productive.

Being attacked through the AI. Once an assistant can read email, documents or web pages, any of that content can carry instructions. EchoLeak (CVE-2025-32711, CVSS 9.3), disclosed by Aim Security in 2025, showed that a single crafted email could cause Microsoft 365 Copilot to pull internal data from its context and send it to an attacker-controlled server, with no click from the user at all (SOC Prime, arXiv). Microsoft patched it server-side and reported no exploitation in the wild. But the pattern, known as indirect prompt injection, is not a single bug. It is a property of systems that mix trusted instructions with untrusted content. A user cannot „be careful“ about an email they never opened.

Installing the wrong tool. Agentic AI lets users connect tools and plugins themselves. In September 2025, Koi Security found postmark-mcp, a fake MCP server on npm that impersonated a legitimate email integration. After fifteen clean releases it added one line of code that blind-copied every outgoing email to an attacker (The Hacker News). To a non-technical user, „add the email connector“ looks exactly like „install an app“. The difference between the real package and the malicious one was one line they would never read.

The cost side is measurable. IBM’s 2025 Cost of a Data Breach report found that breaches involving shadow AI cost on average USD 670,000 more than other breaches, that one in five studied organisations had a breach involving shadow AI, and that 97% of organisations with an AI-related incident lacked proper AI access controls (IBM, Kiteworks summary). Part of that premium is simply not knowing: if you cannot see what was shared, you cannot scope the incident.

So we are stuck between two bad options. Lock it down and lose the value, and the users. Open it up and hope nobody pastes the wrong thing or reads the wrong email.

3. The way out: treat AI usage as something you observe

Mature engineering organisations solved a similar problem years ago. We do not prevent every possible production failure by making systems unchangeable. We instrument them, we trace requests end to end, we alert on anomalies, and we fix fast. Observability made it safe to move quickly.

AI usage needs the same treatment. Instead of asking „how do we stop users from doing anything risky?“, ask „would we notice, quickly, if something risky happened?“ If the answer is yes, you can afford to grant far more useful permissions.

What to trace

A modern AI interaction is not one call. It is a chain: a user request, an agent that plans, several model calls, tool invocations, document retrievals, and a final answer. The OpenTelemetry GenAI semantic conventions now give this a standard shape: an invoke_agent span containing chat spans for each model call and execute_tool spans for each tool use, with the model, token counts and finish reason recorded as attributes (OpenTelemetry). That structure is exactly what you need to answer security questions, not only performance ones:

  • Which user, through which client, triggered this chain?
  • What data sources were pulled into the model’s context?
  • Which tools were called, with which arguments, and where did data go afterwards?
  • Did the output contain an outbound link, image URL or email that the user did not ask for?

What to look for in the traces

With traces in place, leak detection becomes a pipeline problem rather than a policy problem:

  • Sensitive data in prompts and uploads. Run PII, secret and classification detectors over prompt content and attachments. Credentials and API keys in a prompt are an incident on their own.
  • Sensitive data flowing out. Watch tool arguments and outputs, not just prompts. EchoLeak-style attacks exfiltrate through the model’s output, for example an image URL with data encoded in it. Postmark-style attacks exfiltrate through a tool.
  • Unusual tool behaviour. A new MCP server appearing, an unknown destination domain, an email tool suddenly adding recipients, an agent reading far more documents than usual.
  • Shadow usage. Network and browser telemetry pointing to unmanaged AI services tells you where the sanctioned offering is falling short, which is product feedback as much as a security signal.

Observability that does not become surveillance

There is a catch, and it matters. Traces that capture prompts and tool payloads are themselves a concentrated store of exactly the sensitive data you are trying to protect. The OpenTelemetry conventions reflect this: by default they record only metadata, and capturing prompt content and tool arguments is an explicit opt-in (OpenTelemetry).

A workable design separates the two concerns:

  • Detect close to the source, store little. Scan content in the pipeline, for example in an OpenTelemetry Collector processor, and redact or hash before anything is persisted (OpenObserve). Keep structural metadata broadly, and keep content only for flagged events, with short retention.
  • Restrict who can see traces. Access to AI traces should be as tightly controlled as access to the systems they describe.
  • Monitor systems, not people. The goal is to find leaks and attacks, not to score employees. In Europe in particular, monitoring that can be linked to individuals touches data protection and co-determination rules. Involve your data protection officer and, where relevant, employee representatives before you switch it on, not after.

From monitoring to earned permissions

The real payoff is that monitoring changes how you grant access. Instead of a binary allow or deny decided upfront, you can:

  1. Start users on broad, useful read access with strong tracing.
  2. Gate write actions and outbound communication behind confirmations at first.
  3. Use what the traces show, real usage and real near-misses, to tighten the few things that are actually risky and relax the many that are not.

Tight permissions based on fear become targeted permissions based on evidence. That is better for security and much better for adoption.

Conclusion

The choice between „safe but useless“ and „useful but reckless“ is a false one, but only if you can see what your AI systems are doing. Users will adopt AI whether or not the organisation makes it easy. Attackers will target AI integrations whether or not users are careful. The organisations that come out ahead will be the ones that instrument AI usage the way they already instrument production systems, and use that visibility to give their people more capability, not less.

Start with three questions: Do we know which AI tools are in use? Can we trace what data enters and leaves them? Would we notice a leak within hours rather than months? If any answer is no, that is where the work begins.

Need help finding the right balance?

If you can’t answer one of the three questions above with a confident yes, we can help. We support organisations in selecting the right AI tools for their use cases, defining guardrails and monitoring that enable safe use without blocking it, and putting the organisational measures in place, from usage policies and roles to rollout and training.

Get in touch with our team to discuss where your organisation stands today.

Sources

Ready to automate your business?

Realize your business success - with NEOZO Intelligence as your partner for automation, AI and data

Connect with us