Artificial Intelligence Agents

What AI agents are and why they are different from ordinary automation

artificial intelligence agents are not just chat interfaces with a model behind them. They are software systems that can interpret context, choose a course of action, and execute steps with some degree of autonomy, which means their behaviour can change at runtime rather than being fully scripted in advance.

That distinction matters because the security question is no longer only “what did the user ask?” but also “what was the agent allowed to do, on whose behalf, and with what evidence trail?” A useful framing is the difference between an assistant that suggests and an agent that acts, especially when tool calls, data access, or external side effects are involved.

Authority, permissions, and delegated action

Once an agent can call tools or reach back-end systems, its permissions become a control surface of their own. The core issue is delegated authority: the agent should only have the minimum access needed for the specific task, and that access should be scoped to the action, context, and time window rather than treated like a permanent operator role.

For a practical explanation of that model, NHIMG’s AI Agent Authorisation Guide is the most direct reference for task-scoped access, per-action policy decisions, and human approval gates. When agents are allowed to act across multiple systems, authorisation should be evaluated at the action boundary, not just at login.

That is also why identity for an agent is not the same thing as identity for a human operator. An agent may inherit a user intent, but it still needs its own rules for delegation, token use, and revocation so that privilege does not silently expand as the session continues.

Identity, auditability, and accountability

Agentic systems create accountability problems when action attribution is weak. If multiple users, services, and automation layers are involved, organisations need to know which principal authorised the action, which identity executed it, and which downstream systems were touched. Without that separation, incident review becomes guesswork.

NHIMG’s AI Agent Observability, Audit and Incident Response Guide is useful here because it focuses on logging, attribution, and kill-switch design for agents. The operational goal is to preserve a trustworthy action trail that can support both security investigation and business accountability.

Auditability is not just about storing logs. It also depends on whether the log records capture the agent’s decision context, the tool invocation, the identity presented to the target system, and any approval or policy decision that preceded the action.

Trust boundaries, failure modes, and system design

AI agents expand the attack surface because they connect reasoning, memory, tools, and external systems in one loop. A failure in any one of those layers can produce unintended actions, data leakage, or privilege abuse, especially when the agent is allowed to chain steps across systems without fresh review.

NHIMG’s Agentic AI Security Guide is a strong companion for understanding how inputs, memory, tools, orchestration, and identity interact as a layered threat model. For the broader architectural pattern, the OWASP Agentic AI Top 10 formalises the main classes of agentic risk, including goal hijacking, tool misuse, and identity and privilege abuse.

The practical takeaway is that autonomy should be designed as a bounded capability, not an open-ended permission to improvise. The more an agent can alter state, the more important it becomes to constrain tool access, isolate memory, and verify high-impact actions before they execute.

Risk and Threat Considerations

AI agents create material security risk because they can turn a single compromise, bad instruction, or over-broad permission into real-world action. If an attacker can influence the agent’s inputs, tools, or approval flow, the result may be data exfiltration, fraudulent requests, privilege escalation, or unauthorised changes in downstream systems.

Failure mechanism: The agent is trusted to act within a permission set that is wider than the task actually requires, or it is tricked into using that permission in an unintended way. Prompt injection, tool misuse, credential misuse, and delegation abuse are common mechanisms because the agent is allowed to interpret context and then execute.

Impact: Compromise can propagate quickly because the agent often has access to multiple systems, not just one application. That can expose credentials, sensitive data, or privileged workflows, and it can also make post-incident reconstruction harder if the action trail does not clearly separate user intent from agent execution.

Practitioner Guidance

Why practitioners should care: The key governance decision is not whether to deploy agents, but where to place the approval boundary. High-trust tasks may be suitable for autonomous execution, but anything that can change data, trigger transactions, or reach sensitive systems should be bounded by clear policy, short-lived authority, and explicit review points.

Practitioner note: Treat agent security as a combination of authorisation, observability, and containment. If you cannot explain what the agent may do, how it is authorised to do it, and how you would prove what happened later, the design is not ready for production use.

Related resources from NHI Mgmt Group

• What happens when organisations allow AI agents to browse and act without traffic intelligence and enforcement?
• How should organisations make artificial intelligence safer without treating it as a simple safe versus dangerous choice?
• What happens when customer service agents lack real-time identity risk intelligence during claims handling?
• How should teams combine AGENTS.md with live code-intelligence checks in the same repository?