Agents change what security has to control
Agentic AI changes the security conversation because it changes what software can do.
A chatbot that summarises a policy document is primarily a data-handling concern. An agent that can read a customer record, query a warehouse, open a support ticket, change a cloud configuration or initiate a payment workflow is different. It has agency: the ability to select tools, sequence steps and affect live business systems.
That distinction is becoming central to enterprise security. On 28 September, Thales announced expanded work with Google Cloud around protection, visibility and policy enforcement for agentic workflows. The focus is the interaction between agents, models, enterprise data and tools. That is a useful marker of the shift: the question is no longer only whether a model produces safe text. It is whether an agent can be trusted to act within its mandate.
The timing matters. Reuters’ reporting from the Thales cybersecurity gathering describes the growing pace and sophistication of AI-enabled attacks. Organisations are therefore facing two related pressures: attackers can use AI to move faster, while internal teams are being asked to give AI systems access to more consequential workflows.
The response cannot be a better system prompt alone. Prompts are instructions; they are not access controls, audit trails or approval gates. If an agent can call a privileged tool, reach sensitive data and operate with a long-lived credential, a well-written prompt does not materially limit its blast radius.
The right objective is controlled agency.
Why agents create a different security problem
Traditional business applications generally follow a defined path. A user selects an action, the application checks permissions, invokes a known service and records the result. The security model is imperfect, but the possible routes are relatively visible.
An agent introduces a more dynamic execution model. It interprets a goal rather than following one fixed workflow. It can decide which tools to use and in which order, combine internal data with external information, persist context, pass work to another agent and act using delegated permissions. It may also continue a task for longer than a normal human session.
That flexibility is useful. It is also where the risk sits.
Consider an operations agent asked to resolve delayed orders. It may need to inspect stock, contact a carrier, update a customer record and issue a credit where appropriate. Each individual action may be legitimate. The problem emerges when the agent has broad access, weak boundaries or no meaningful approval points. It might disclose customer data to an untrusted destination, issue inappropriate refunds, act on manipulated content in a support ticket or repeatedly invoke a tool outside the intended process.
The failure is not necessarily a malicious model. It may be an over-permissioned system behaving consistently with a badly bounded objective.
The UK National Cyber Security Centre makes this point clearly in its guidance on managing agentic AI risk. Greater autonomy increases the potential impact of malfunction, inappropriate access and activity outside an agent’s intended scope. The level of control should therefore match the consequences of failure.
This reframes governance. The key question is not whether a model is safe. It is what this agent is permitted to do, with which identity, against which systems, under what conditions, and how the organisation will know.
Prompts are a policy layer, not a security boundary
Prompting still matters. Clear instructions reduce ambiguity, define expected behaviour and tell an agent when to stop. They are an important part of a well-designed workflow.
They are not a reliable security boundary.
A prompt can be weakened by conflicting instructions in retrieved content, indirect prompt injection, a tool response that changes the agent’s interpretation of its goal, or a simple failure to preserve context over a long-running task. Even an agent acting in good faith can find an unexpected route to complete an instruction if the technical environment allows it.
The NCSC advises organisations to define what an agent should do, what it should not do, and when it must seek human approval. It also warns against relying on prompting alone. Its guidance recommends technical and operational controls around the agent.
Prompting can influence the intended task, preferred process and expected guardrails. Controls must enforce which tools the agent can call, which data it can access, which actions require approval, which identity and permissions it receives, and what is logged. An agent should not be able to bypass a restriction simply because it finds a more persuasive instruction elsewhere in its context.
Start with an agent identity, not a shared credential
Every production agent should have a distinct, non-human identity.
That identity should be recognisable in identity systems, logs, audit records and downstream applications. It should not be a shared service account inherited from the host machine, a developer’s long-lived token or a generic integration credential that hides who, or what, performed an action.
A separate identity makes several things possible:
- Permissions can be scoped to the agent’s actual role.
- Activity can be attributed to a particular workflow and owner.
- Credentials can be revoked without interrupting unrelated systems.
- An agent can be prevented from inheriting a human user’s broader access.
- Security teams can distinguish agent behaviour from normal application or employee activity.
The NCSC specifically recommends unique identities that distinguish agents from people and other systems, alongside short-lived credentials and task-specific permissions. It also notes that credentials exposed to an agent form part of its potential blast radius. Read the relevant guidance.
In practice, treat an agent identity as a first-class workload identity. Give each agent or agent class its own identity; issue short-lived, renewable credentials; scope access to a defined set of resources and actions; and put tool access behind a policy enforcement point where possible.
A proxy or broker can be especially useful. Instead of handing an agent a reusable API key, the agent requests a narrowly scoped action from a broker. The broker evaluates policy, injects the appropriate short-lived credential and records the request. The agent receives the result, not the secret.
This is familiar territory for cloud consultancy and platform teams: strong identity, least privilege, segmentation and observable control planes are established practices. Agentic AI does not replace them. It gives them a new and more demanding consumer.
Control tools as carefully as data
Most agent risk is realised through tools.
An agent may be connected to APIs, databases, SaaS platforms, workflow engines, code repositories, messaging systems or cloud management interfaces. A tool connection turns intent into an external action. That makes tool governance central.
For each tool, organisations should define the operations the agent may perform, the resources it may target, the data classifications it may read or write, any value or environment limits, whether the action is reversible, whether human approval is required, and the evidence that must be logged.
This is more granular than allowing access to Salesforce, AWS or the finance system. An agent permitted to retrieve a customer’s support history does not automatically need permission to edit account ownership. An agent that can create a draft purchase order does not need authority to submit it. An agent that can inspect cloud configuration does not need to change production network rules.
The OWASP State of Agentic AI Security and Governance frames this as both a governance and technical-design problem. Its wider agentic security work focuses attention on tool misuse, identity and privilege abuse, memory and data risks, rather than unsafe outputs alone.
A useful pattern is to classify tools by consequence:
- Read-only: retrieval and analysis with no state change.
- Low-impact write: creating drafts, tickets or non-production records.
- Controlled write: changing business records, triggering communications or modifying managed resources.
- High-consequence action: payments, production infrastructure changes, privileged access changes, legal commitments or data deletion.
The higher the consequence, the tighter the policy and approval requirements should be.
Data access needs purpose and scope
Data access is often treated as an extension of model access. It should be treated as a separate security decision.
An agent may be technically capable of using a data source without having a business reason to retrieve all of it. If its role is to classify incoming service requests, it may need the request, the customer account tier and relevant knowledge-base content. It may not need HR information, full billing history or unrestricted document search.
A practical data policy should answer which data categories an agent may access, for which approved workflow, at what level of detail, whether it can export or combine information across systems, how long it may retain context, and what should be redacted before content reaches the model.
This is where data engineering and governance disciplines become inseparable from AI delivery. Data contracts, classification, lineage, access policy and quality controls are not back-office concerns when an agent is making decisions based on enterprise data. They are part of the operational safety model.
Retrieval should also be contextual. An agent should receive the minimum set of approved information necessary for the step it is performing, rather than blanket access to every potentially useful source. This limits accidental disclosure and reduces the opportunity for untrusted content to influence a high-privilege action.
Human approval should sit at consequential boundaries
Human-in-the-loop is often used as a reassuring phrase without enough precision. A person watching a dashboard is not the same as a person approving an action before it happens.
The NCSC distinguishes between human-in-the-loop, human-on-the-loop and fully autonomous operation. For high-risk activity, it recommends human oversight alongside technically enforced controls. Its guidance is especially useful here: approval points need to be guaranteed and gated, not merely requested by the agent.
A good approval design identifies moments where the impact changes materially. These may include sending a customer communication generated from sensitive data, committing a financial transaction, changing a production configuration, granting access, deleting records, sharing data outside the organisation or escalating a case based on legal, regulatory or safety criteria.
The agent can prepare the action, explain its reasoning, assemble the relevant evidence and propose the next step. A named person or authorised group then approves, rejects or modifies it through a system-enforced gate.
Approval should not become a manual bottleneck for every low-risk task. The better approach is progressive autonomy: start with read-only or draft workflows, prove that controls and monitoring work, then increase scope only where the risk and business case justify it.
That approach is consistent with the joint international guidance on careful adoption of agentic AI services, which encourages organisations to assess threats arising from components, integrations and downstream use, not just the model itself.
Audit trails must reconstruct the action, not only the answer
If an agent makes a consequential decision, an organisation should be able to reconstruct what happened.
That does not mean retaining every detail without thought. Agent logs can contain sensitive data and must themselves be protected. It does mean recording enough evidence to answer operational and forensic questions:
- Which agent acted, and on whose behalf?
- Which workflow, policy and model version were used?
- What tools were called, and what data sources were accessed?
- Which permissions and tokens were used?
- What policy decision allowed or blocked the action?
- Was human approval required, and who provided it?
- What changed in the target system, and can it be reversed?
The NCSC recommends treating agent activity as a form of user activity, bringing it into security operations monitoring and incident response. It calls for telemetry from both the agent and its wider environment, including access logs, proxies and network traffic, and advises protecting logs from modification or deletion. See the observability guidance.
This has direct implications for cybersecurity services. Security teams need an agent-aware view of identity events, data access, tool calls and abnormal behaviour. Standard SIEM and incident-response processes remain useful, but they must be able to identify agent execution chains and distinguish expected automated work from unauthorised activity.
A practical starting point
Organisations do not need to solve every agentic AI use case at once. They do need a clear route from experimentation to controlled operation.
Start with a bounded workflow that has measurable value and limited consequence. Give the agent a unique identity, a small tool set, restricted data access and short-lived credentials. Place high-impact actions behind approvals. Capture telemetry from day one. Test what happens when an agent receives malicious or conflicting instructions, encounters unexpected tool responses or attempts to exceed its authorised scope.
Then review the evidence before expanding access.
The organisations that get value from agents will not be those that give them the broadest permissions first. They will be the ones that make each capability earned: observed in a constrained environment, governed by policy and expanded only when the business benefit outweighs the additional risk.
Agentic AI needs room to act. It also needs boundaries that hold when the prompt does not.
