Closing the Gaps in My AI Agent's Identity Setup

Quick note before I start. I’ve got mild dyslexia, so I use AI tooling to help with my writing, but the thoughts are all mine.

In my last article I gave an AI agent access to a small fake company four different ways, then tried to break each one.

The “best” setup did well:

• a token for one service and one task at a time;
• the token names both the person and the agent;
• it’s bound to a key and expires in two minutes.

It still left some holes. A reader who knows enterprise identity far better than me then went through the code and found a few more. So I went back and tried to close them.

The six gaps

1. Copying the agent’s tokens and its client secret let an attacker take over for 8 hours.
2. The approval step lived in the agent’s own tool server. Anyone who went round it, straight to the expenses service, skipped it. It was also only a stub: it recorded the request and stopped.
3. Nobody checked what the agent itself was allowed to do, only what the user and the task allowed.
4. No identity check asked whether a claim was genuine. A small claim with a fake “pre-approved by Finance” note would sail through.
5. The agent kept trying staff-directory lookups (23 refused) just to work out who’d submitted each claim.
6. The tool server didn’t check who was calling it.

What I changed

• A private key instead of a client secret. The agent’s tool server proves who it is to Keycloak by signing a fresh, short-lived note with a private key (private_key_jwt). Keycloak only ever holds the public half. In real life that key would live in a hardware module or a cloud key vault, where it can’t be copied.
• A confirmation the service itself insists on. For any approval over £1,000, the expenses service now demands a special token that names that one claim. The only way to get it is for the approver to say yes on their own phone. That’s a standard flow called CIBA, which Keycloak supports. The agent’s own login can’t produce that token at all.
• The phone shows facts the agent didn’t write. The message is built from the expenses system’s own data: claim, amount, receipt or not, and who submitted it.
• Each service checks the agent’s own permissions. The assistant can never read salaries, whatever the user or the task allows.
• The expense list says who submitted each claim, so the agent doesn’t need the staff directory.
• The tool server needs a per-session token that only the agent it was started for holds.

I also added two claims to Bob’s queue:

• a real £1,450 laptop claim, with a receipt;
• a £900 “training course” with no receipt and the same fake “pre-approved by Finance” note as the £4,800 invoice.

What worked

The private key closed the takeover. I copied everything a thief could plausibly get from the tool server’s config and logs: the tokens, plus a signed note the tool server had already used. None of it worked:

• reusing the note: “Token reuse detected”;
• waiting until it expired: “Token is not active”;
• signing a fake one: signature check failed.

The same test against the client-secret version still let me take over, as before.

The phone confirmation stopped the £4,800 invoice every time. The agent tried to approve it in 4 of 5 runs. Each time Bob’s phone showed the claim and Bob (scripted, approving only claims with a receipt) said no. The real laptop claim was confirmed and approved in all 5.

What I like most is that it’s the service insisting on this:

• a normal approve token couldn’t do it;
• the agent’s own login couldn’t ask for it;
• a confirmed token for one claim didn’t work on another;
• even with the tool server’s own keys stolen, the big claim was refused.

The other three did what they said.

• Agent capabilities: a salary read was refused for the agent even though Bob was allowed to see it and the task allowed it.
• Claimant details: in 10 runs the agent made no directory lookups at all, compared with 23 refused last time, and still finished every job.
• The tool server’s front door: another process calling it without the session token got a flat 401.

What didn’t, and why that’s the real lesson

The £900 claim was approved in 4 of 5 runs.

Every check passed:

• It really was Bob.
• The agent was allowed to approve expenses.
• The task included approvals.
• Bob manages the claimant.
• It was under the phone-confirmation limit.

The only thing wrong with it was that it was fake. None of my controls asks that question.

This is the point the reviewer made, and the follow-up proves it rather nicely. Identity tells you who’s acting. Authorisation tells you whether they may. Neither tells you whether the action is a good idea. That needs business rules where the business data lives: “no receipt, no approval”, or “check FIN-22 actually exists”.

Funnily enough, the agent tried to check. In one run it went to look up the “FIN-22” and “FIN-23” references, and got refused, because reading tickets wasn’t part of the expense task. Narrow permissions and verifying things pull in opposite directions, and someone has to design for both.

Three bits of enterprise reality

• Keycloak’s phone message can’t hold a sentence. It’s limited to 50 characters with no spaces. The most “raw facts” I could fit was EXP-9/4800GBP/no-receipt/Dave. A real deployment needs an approval app that looks up the claim and shows it properly.
• The approver is now the last line of defence for big claims. In a scripted test where the attacker also held the approval client’s key, a careful approver stopped it and a careless one let it through.
• Words in tool results matter. My tool server told the agent Bob “did not confirm” the invoice. In all 4 runs the agent told Bob the claim was still waiting for his confirmation, when he’d actually said no. Say “Bob declined”, not something that can be read as “pending”.

What I’d do

1. Authenticate agents with a private key held somewhere it can’t be copied, not a client secret in a config file.
2. Make high-value actions need a token only the person’s own confirmation can produce, and have the service check it.
3. Build the confirmation message from the system of record, not from the agent.
4. Check the user, the agent, the task and the business rule separately.
5. Give the agent the context it needs through the owning service, not wider access.
6. Lock the tool server’s front door.
7. Put business validation next to the business data. Identity won’t do it for you.

The whole follow-up cost $0.06 in model time for 10 runs. The full report has every scripted test, and the design was pushed before any run.

← All architecture