My Agentic AI Close Call
A few weeks ago I was generating system architecture documentation in a Claude chat session. Partway through, I noticed that the agent had found an API for an unfamiliar third-party service — and was about to send the full source to an external server. I stopped it.
I've been working in IT for twenty years, and with AI systems for several years. It happened to me anyway — because agentic AI requires a different way of working than the tools we've used before, and we're all still learning that.
This wasn't a malfunction. Claude was optimizing for the task. The first attempt — local rendering with PlantUML — failed because of a missing dependency. So it found an alternative, and without asking, was about to send confidential architecture data to a third-party server. It didn't break a rule, because I never explicitly said to use local rendering only — just that it was working with sensitive data.
The same pattern appears in a documented GitHub issue against Claude Code. A developer had explicitly recorded a prohibition in their CLAUDE.md file: never print secret values. Claude Code honored the instruction — but then wrote the secrets to a temporary file to pass them between steps, without flagging it. Technically compliant. Operationally not what was intended.
Neither of these is a bug. Both are examples of an agent doing exactly what agents do: finding a path to task completion. The risk isn't that agentic AI misbehaves. The risk is that it behaves — competently, autonomously, and within the literal boundaries of what it was told — in ways the operator didn't anticipate.
What this means for enterprise governance
The standard enterprise response to AI risk is a policy: a list of approved tools, a list of prohibited actions, a training module. This works reasonably well for individual AI use. It doesn't work for agentic AI.
An agent doesn't read the policy. It executes within the constraints it was given — in its system prompt, in its tool configuration, in the explicit instructions of the task. If those constraints don't cover a specific situation, it will find a solution. That solution may be exactly right, or it may be exactly wrong in a way that's hard to detect after the fact.
This means governance has to move from the policy level to the architecture level. The question isn't "what are employees allowed to do with AI" — it's "what can this agent actually do, in this context, with this data, and what are the boundaries of its autonomy."
That's a different kind of work. It requires thinking about each agentic use case individually: what actions the agent can take, what data it can access, what fallback behaviors are acceptable when a primary path fails, and where human oversight is required.
At Intuitech, this is the work we do with enterprise clients on every agentic deployment: a structured evaluation of every use case, its risk profile, and the configuration that delivers the most functionality while staying within an acceptable risk boundary.