Securing AI agents -

Securing AI agents: From robust identity management to comprehensive runtime protection

By Kootek Consulting 27th October 2026
A practical, ten-point guide for security, risk and technology leaders

A chatbot that gets an answer wrong is embarrassing. An AI agent that gets an action wrong is a different matter entirely. Agents book, query, approve, deploy and delete. They hold credentials, call APIs and chain decisions together at machine speed, often with nobody watching in real time.That shift changes the security question. It is no longer just “is the model safe?” but “who is this agent, what is it allowed to do, and what is it doing right now?” The first half of that question is identity control. The second is runtime defence. Governance is the thread that ties them together.Here are ten ways to secure AI agents, moving from the front door (identity) to the factory floor (runtime).

Part one: Identity control

1. Give every agent its own identity

The most common anti-pattern we see is an agent running on a shared service account, or worse, a developer’s personal token. When something goes wrong, the logs say “service-account-7” and nobody can say which agent, which workflow or which human authorised it.Treat agents as a new class of non-human identity, distinct from both employees and traditional service accounts. Each should be individually named, owned and traceable.

What good looks like

•One identity per agent, never shared between agents or environments

•A named human owner and a documented business purpose

• Identities registered in your identity provider, not hard-coded in prompts or config files

2. Replace long-lived secrets with short-lived credentials

API keys pasted into an agent’s configuration are the new password sticky note. They get copied into repositories, logged in traces and echoed back in model outputs. The longer a credential lives, the more attractive it becomes.Move to short-lived, automatically rotated tokens issued at the point of use, using workload identity federation or a secrets manager. If a token leaks, it should expire before an attacker can do much with it

What good looks like

• Credentials measured in minutes or hours, not months

• Secrets never placed in prompts, context windows or tool descriptions

• Automated detection of exposed keys in code, logs and agent transcripts

3. Enforce least privilege on every tool and data source

OWASP’s guidance on LLM applications lists excessive agency as a core risk, and it is easy to see why. Agents are often handed broad permissions “so they can be useful”, which means a single manipulated instruction can reach far more than it should.Scope access to the task, not the team. An agent that summarises support tickets does not need write access to the CRM. An agent that drafts invoices does not need to approve payments.

What good looks like
• Read-only by default; write and delete rights granted explicitly and separately

• Tool allow-lists per agent, rather than a blanket toolbox

• Data access limited by classification, so sensitive stores need a stronger justification

4. Make delegated authority explicit

When an agent acts on behalf of a person, whose permissions does it use: the user’s, its own, or some blend of the two? If you cannot answer that clearly, you have a confused-deputy problem waiting to happen, where an agent with high privileges is tricked into doing something its user could never do.Use on-behalf-of flows so the agent’s effective access is the intersection of what the user may do and what the agent is permitted to do. Then place human approval in front of high-impact actions such as payments, external communications, production changes and bulk data exports.

What good looks like

• Clear delegation rules, recorded and reviewable

• Risk-tiered approvals: low-risk actions flow, high-risk actions pause for a human

• Approvals that show the actual action and its parameters, not a vague summary

Kootek insight: Approval fatigue is real. We help clients design tiered authority models so humans are asked to approve the few decisions that matter, rather than rubber-stamping hundreds that do not.

5. Govern the whole lifecycle, including the agents you did not know about

Agents are easy to create. A motivated team can stand one up in an afternoon using a low-code platform and a few connectors. Within months, you have agents nobody inventoried, with access nobody reviewed, owned by people who have since changed role.

Identity control is not complete until you can answer three questions: what agents do we have, who owns them, and when were their permissions last reviewed? Build an agent register and bring it into your joiner, mover and leaver processes.

What good looks like

• A living inventory of agents, their purposes, data access and owners

• Periodic access reviews, with automatic expiry for unused permissions

• A formal decommissioning step, so retired agents do not leave live credentials behind

Part two: Runtime defence

Even a perfectly governed identity can be misdirected once it is running. Agents read emails, browse pages, parse documents and call other agents. Every one of those inputs is a potential instruction. Runtime defence assumes that something will eventually get through and focuses on limiting what it can do.

6. Assume every input is hostile: defend against prompt injection

Prompt injection remains one of the most stubborn weaknesses in agentic systems. Direct injection comes from the user. Indirect injection is more insidious: hidden instructions embedded in a web page, a PDF or a calendar invite that the agent dutifully reads and then obeys

There is no single filter that solves this. The sound approach is layered: separate trusted instructions from untrusted content, constrain what the agent can do after reading untrusted material, and never let a model’s output be the only thing standing between an attacker and a sensitive action.

What good looks like

•Clear separation between system instructions and retrieved or user-supplied content

•Reduced privileges when an agent is handling untrusted data

• Output validation before anything is passed to a tool, a database or another agent

7. Enforce policy at the action layer, not just in the prompt

“Please never delete customer records” is a request, not a control. Models can be persuaded, confused or overridden. Security rules must be enforced deterministically, outside the model, at the point where the agent tries to do something.

Place a policy gateway between agents and their tools. Every call is checked against rules covering who is asking, what they are asking for, on which data, and in what context, before it is allowed to proceed.

What good looks like

• Policy-as-code evaluated on every tool call, independent of the model

• Parameter-level checks, such as spend limits, recipient domains and record counts

• Hard denials that the agent cannot talk its way around

8. Sandbox execution and control egress

Agents that write and run code, browse the web or manipulate files should do so in isolated environments with tightly controlled network access. If an agent is compromised, the sandbox is what turns a potential breach into a contained incident.

Restricting outbound connections is especially valuable. Many injection attacks succeed only if the agent can send data somewhere the attacker controls. Remove that path and you remove much of the payoff.

What good looks like

•Ephemeral, isolated execution environments with no persistent access to production

• Default-deny outbound traffic, with approved destinations only

• Resource limits to prevent runaway loops, cost explosions and denial-of-wallet abuse

9. Monitor behaviour and keep audit-grade logs

Traditional monitoring asks whether a system is up. Agent monitoring must ask whether it is behaving. That means capturing prompts, retrieved context, tool calls, parameters, outcomes and approvals in a form you can actually investigate.

Baseline normal behaviour and alert on departures from it: an agent suddenly touching new datasets, calling unusual tools or acting at odd hours. Good logging is also your evidence trail. Regulators, auditors and customers increasingly expect you to show how AI decisions were made and controlled.

What good looks like

• End-to-end traces linking user request, agent reasoning steps, tool calls and results

• Behavioural alerts integrated into your existing SOC workflows

• Retention and access controls on logs, which often contain sensitive data themselves

Kootek insight: As a listed Drata partner, Kootek Consulting helps organisations turn controls like these into continuously monitored, audit-ready evidence, so AI governance becomes part of everyday compliance rather than a scramble before an assessment.

10. Plan for failure: kill switches, incident response and red teaming

Every agent should have an off switch that works, and someone who knows how to use it. Define in advance what triggers a shutdown, who can pull the lever, and how you revoke credentials, quarantine memory and roll back actions.Then test it. Red-team your agents with realistic attack scenarios, including injection through documents, tool misuse and privilege escalation, and feed the findings back into your controls. Update your incident response playbooks so they cover agent-specific scenarios, not just compromised laptops and phishing.

What good looks like

• A tested kill switch and rapid credential revocation for every production agent

• Agent-specific incident playbooks and tabletop exercises

• Regular adversarial testing, with findings tracked through to remediation

The ten controls at a glance

Number	Control	Potential risk it solves
1	Unique agent identities	Anonymous actions; no accountability
2	Short-lived, scoped credentials	Stolen or leaked long-lived keys
3	Least-privilege tool access	Excessive agency and blast radius
4	Delegated authority and approvals	Agents acting beyond a user’s intent
5	Lifecycle governance	Shadow agents and orphaned access
6	Prompt-injection defences	Hijacked goals via hostile content
7	Action-layer policy enforcement	Unsafe or unauthorised tool calls
8	Sandboxing and egress control	Data exfiltration and lateral movement
9	Behavioural monitoring and audit trails	Silent drift; weak evidence for regulators
10	Kill switches and red teaming	Slow, uncoordinated incident response

Where governance ties it together

Identity and runtime controls are the mechanics. Governance is what makes them consistent, defensible and repeatable. It answers the questions boards, regulators and customers are starting to ask: who is accountable for each agent, what risks have been assessed, which standards are we aligned to, and how do we know the controls are working?

In practice, that means mapping your agent controls to recognised frameworks such as the NIST AI Risk Management Framework, ISO/IEC 42001 and, where relevant, the EU AI Act, alongside UK expectations from the NCSC and the ICO. It also means assigning clear ownership, setting risk appetite for autonomous action, and building review cycles that keep pace with how quickly agent capabilities change.

This is where many organisations stall. Security teams understand the technology but lack a governance structure. Compliance teams understand the frameworks but not how agents actually behave. The value lies in bridging the two.

How Kootek Consulting can help

Kootek Consulting works with organisations at exactly that intersection of AI, security and compliance. We help teams to

• Establish AI governance: policies, ownership, risk tiering and approval models that fit how your business really works

.• Assess your agent estate: inventory agents, review identities and privileges, and pinpoint where excessive agency is hiding.

• Design practical controls: from delegated authority models to runtime guardrails and monitoring requirements

.• Prove it: align to recognised frameworks and automate evidence collection so you stay audit-ready as you scale.

Next step: Not sure where your AI agents sit on this list? Book a no-obligation AI governance conversation with Kootek Consulting and we will help you identify your three highest-priority gaps.

Click to Book an appointment with us

Send us an email: support@kootek.co.uk

Our final thought

Agents will only be trusted with meaningful work if they are controlled like meaningful workers: given an identity, granted only the access they need, supervised while they act, and stopped quickly when they stray. Start with identity, build towards runtime defence, and wrap both in governance. Organisations that do will be able to adopt AI agents faster and with far more confidence than those that bolt security on afterwards.