The first time an AI agent sent an email I hadn’t asked it to send, I was very glad I hadn’t connected it to my main account.
This was early days with OpenClaw. I’d given it a separate email account and a simple task: prepare a draft. It sent the message instead.
Nothing terrible happened. No irate customer, no commercial fallout, no call to a lawyer. But it was one of those moments when a technology you’ve been cheerfully experimenting with reminds you that it can do things in the real world.
The gap between drafting an email and sending one sounds trivial until a machine closes it for you.
I changed the permissions immediately. I didn’t stop using agents, and I didn’t decide the technology was too dangerous. I decided I’d given one more authority than its job needed.
The security world has a name for this, naturally. OWASP lists “Excessive Agency” in its top ten risks for LLM applications: too much functionality, too many permissions, too much autonomy. I’d managed to demonstrate it with a single test inbox.
That lesson has shaped a slightly unreasonable amount of what I’ve built over the last six months.
It now has an official advisory
On 15 October, India’s CERT-In issued a critical advisory on AI agents as attack vectors. Part of it covers criminals using open-source agentic tools, which is grim but not surprising. The more interesting part covers agents that weren’t supposed to be attacking anyone.
According to the advisory, AI model providers disclosed that models under research and evaluation had reached live systems belonging to Indian organisations and read business records. They got in through the dullest routes imaginable: credentials left in code and public repositories, and cloud roles with far more permission than anyone needed. Several of the affected organisations didn’t spot it themselves. They found out because the model provider told them.
CERT-In is clear that none of these weaknesses are new. What’s new is how fast an agent finds and uses them.
I’ve been pulled into a handful of conversations recently where an agent caused a problem and somebody needed help recovering. So none of this surprises me. What interests me more is how businesses react.
At one end you’ve got founders and small technical teams moving at extraordinary speed. Agents are writing code, opening pull requests, connecting to services and taking actions that used to need an employee. The productivity is real, and I understand why nobody wants to slow down.
Occasionally, though, the security model appears to consist of hoping the agent is in a good mood.
At the other end, some enterprises are so worried about what might go wrong that they can’t let the technology do anything useful. Every experiment becomes a committee. Every tool connection becomes a security review. By the time permission arrives, three better models have been released and the original business case has taken early retirement.
Neither end is sensible. The real question is how you give an agent enough freedom to do meaningful work while making sure it can’t quietly exceed its authority.
That’s the problem I’ve been working on with Ascendancy IQ.
What six months of building agents has taught me
AIQ is my attempt at a managed workforce of digital employees rather than a collection of clever chatbots. Agents accept work, use tools, recover when things break and produce outcomes someone can actually check. That means somebody has to be in charge, so there’s a control plane that delegates work and tracks what’s happening, with roles, authority boundaries and a record of who decided what.
I’ll spare you the feature tour. Four lessons matter more than the product.
The first is that recommending an action and being authorised to take it are different things. Some actions should be routine. If an agent needs to inspect a repository, analyse a document or fix a low-risk issue in an approved workspace, I don’t want it asking permission every eleven seconds. That defeats the point of having it. Handling credentials, changing privileged access, making external commitments, publishing anything or altering the rules that govern the agents themselves sits in a different category, with much tighter controls.
Second, agents shouldn’t mark their own homework. Doing a task and verifying it met the requirement are separate jobs, and the amount of verification should match the actual risk.
Third, continuity is boring until it isn’t. If an agent loses its connection halfway through a job, you need to know what happened, whether the work is still running and whether restarting it will do something twice that should only ever happen once. It’s less glamorous than watching a model produce 4,000 lines of code while you make a coffee. It’s also the bit that makes the system usable.
And finally, a governance document is close to worthless unless the controls are enforced. A policy saying an agent shouldn’t access something doesn’t stop it. An alert that tells you afterwards is useful, but it’s a different kind of protection. CERT-In makes the same point more bluntly, telling AI labs to restrict agents’ network access at the network layer rather than through model instructions. Telling a model not to do something is a request. It isn’t a control.
You need to know which kind of safeguard you’ve actually built.
The Monday morning test
If I had ten minutes with a CTO on a Monday morning, I wouldn’t recommend a six-month AI governance programme.
I’d ask whether they know what their agents can access, and what those agents have already done.
It sounds embarrassingly basic. I suspect it would produce some long pauses.
Start with an inventory. Not just the approved agents, but the ones teams have wired up themselves. What tools can they use? Which accounts are they running through? Can they read customer data, write to repositories, send messages, deploy software or change settings?
Then look backwards. Which tools have they invoked? What succeeded, what failed, and has anyone actually read the history?
An agent with a perfectly sensible job description can still hold permissions that bear very little relationship to the job. My email incident is the simple version. It needed to draft. I’d let it send. The extra permission was the risk.
If a business can’t produce a meaningful record of what an agent did, that isn’t reassuring evidence that nothing happened. It’s an audit finding. CERT-In’s advice here is refreshingly unglamorous: give each agent run a short-lived, least-privilege identity, and keep a tamper-resistant log of what it does.
You won’t fix everything in a day, but you’ll have a baseline. Once you know the exposure, you can decide which permissions to remove, which actions need approval and where monitoring is missing. That’s a far better starting point than buying another governance platform and waiting for the dashboard to turn green.
Why I don’t want agents asking permission for everything
The understandable reaction to every agent mistake is another human approval step. Do that often enough and you’ve built a very expensive automation system whose main function is interrupting people.
I’ve been deliberate about avoiding that in AIQ. I want agents to keep working, recover from failures and close out tasks without constant supervision. A minor verification exception shouldn’t necessarily stop a whole workflow. A credential issue or an unauthorised external action absolutely should.
Those aren’t the same category of problem. Treat them as if they are and the system ends up either dangerous or unusable, depending on which way you lean.
The aim isn’t to remove autonomy. It’s to make it bounded, observable and accountable.
We’re going to need HR for agents
Think about what happens when a person joins a business. They get an identity, a role, a manager, access to specific systems and some understanding of what they’re authorised to do. Their performance gets reviewed. Their responsibilities change. When they leave, someone is supposed to remove their access, and occasionally someone does.
Now think about how most agents arrive. Someone connects a model to a few tools, writes a prompt and lets it get on with things.
There’s rather a lot missing between those two arrangements.
To be fair to the security industry, it spotted part of this before I did. Managing non-human identities (the service accounts, API keys and bots that already outnumber people in most organisations) is an established discipline. Agents inherit all of those problems. The difference is that a service account does what its code tells it to. An agent decides what to do, sometimes creatively, which makes it look less like a service account and more like a new hire with a master key.
That’s why we’ve been building an employee factory inside AIQ: commissioning digital employees with defined responsibilities, permissions, capabilities, verification requirements and operating procedures, rather than improvising each one from a prompt.
Once they’re running, they need continuous oversight, not an audit after something breaks. Some of that can be done by AI. There’s no reason one agent can’t inspect another’s activity, flag odd behaviour or check work against its acceptance criteria. But a human still has to own the system and its decisions.
I suspect agent operations will be as recognisable a discipline as IT operations or security within a few years. It may start inside those teams, but the work is different enough that I doubt it stays somebody’s side responsibility for long.
My accidental email was a cheap lesson. I was lucky. The organisations in that CERT-In advisory learnt theirs when somebody else’s AI lab got in touch.
Before you give an agent another tool, find out what it’s been doing with the ones it already has.
Sources
