BRANDBUSTERS SIGNAL / 08 · AI AND CYBERSECURITY
An AI agent has access to the business. Who controls what it can do?
The risk does not begin when a model produces a wrong answer. It begins when it can read email and documents, use employee accounts, invoke tools, update systems or communicate on behalf of the business. The more an agent can do, the less its security depends on the prompt itself and the more it depends on identity, permissions, architecture and the ability to stop it.
- 15 MIN READ
- AI · RISK · CONTROL
- UPDATED: OCTOBER 2026
08 / 01
An assistant advises. An agent can take action.
The first wave of generative AI deployments in business focused on writing, finding information, summarising documents and supporting decisions.
The risk remained relatively limited while a person copied the output, checked it and carried out the action themselves.
An agent changes that relationship. It may receive access to email, calendars, CRM, customer service systems, documents, product catalogues, development environments or external APIs. It can carry out a sequence of steps, use the results of other tools and act on a user’s behalf.
A mistake is then no longer just an incorrect sentence. It can become:
- —a message sent to the wrong person;
- —disclosure of confidential information;
- —a change to a system record;
- —retrieval of a malicious instruction from a document or website;
- —an action performed with excessive permissions;
- —a decision that cannot easily be reversed.
The model may propose an action. Whether that action is permitted should be decided by a system outside the model.
FROM ANSWERS TO ACTION
An AI agent can do more than generate content: it can use tools and perform successive steps in a process.
Source: NIST — Accelerating the Adoption of Software and AI Agent Identity and Authorization ↗PROMPT INJECTION
A malicious instruction may appear not only in a user’s message, but also in a website, document, email or tool result retrieved by the agent.
Source: OWASP GenAI Security Project — Prompt Injection ↗GUARDRAILS ARE NOT ENOUGH
NIST identifies the need to separate model reasoning architecturally from the system that makes deterministic access decisions.
Source: NIST — Design Tenets for Agent Identity Management Systems ↗08 / 03
An agent should not inherit all of a user’s trust.
The simplest deployment connects an agent to an employee’s account and gives it the same systems, data and permissions.
That is convenient, but unsafe. An employee may have broad access because they understand the organisational context, policies and consequences. A model does not carry the same responsibility or ability to assess the situation.
An agent should have its own identity, a precisely defined purpose and only the permissions needed for a specific task.
If an employee can:
- —read the entire mailbox;
- —export the customer database;
- —change permissions;
- —delete files;
- —send messages;
- —approve expenditure;
- —run code;
that does not mean an agent acting on their behalf should automatically receive all those capabilities.
Agent security does not mean trusting the model to make the right decision every time. It means designing the system so that one mistake cannot cause disproportionate harm.
08 / 04
A prompt is not a security boundary.
- CONTROL BOUNDARY ↓
STAGE 05 / 08
ACCESS POLICY
DETERMINISTIC
- authorisation
- limits
- approval
- execution
- audit trail
- revocation of access
The model may assess and recommend. Critical decisions about access, limits and execution should be enforced outside the model.
08 / 05
Not every agent needs the same level of autonomy.
00INFORMS
The agent retrieves, analyses or summarises information. It cannot change systems.
Example: Preparing a report summary.
01PROPOSES
The agent drafts an action, but a person carries it out themselves.
Example: Drafting a response to a customer.
02ACTS AFTER APPROVAL
The agent prepares a specific operation that a person reviews and approves before execution.
Example: Updating a selected CRM record.
03ACTS WITHIN BOUNDARIES
The agent performs reversible actions within a precisely defined scope, limit and time window.
Example: Categorising support requests and routing them to the appropriate queue.
04HIGH AUTONOMY
The agent performs a sequence of actions with significant consequences without approval at every step.
Example: Changes to production, permissions, finances or external communications.
Requires a specific justification, independent controls, least privilege, full observability and a tested emergency shutdown mechanism. In many processes, this level will not be appropriate.
The level of autonomy should reflect the consequences of a mistake, not what the model can technically do.
08 / 06
Eight control layers for an AI agent
- 01
REGISTER AND OWNER
We know which agents are running, why they exist and who is accountable for each one.
- 02
AGENT IDENTITY
The agent is neither an anonymous process nor a direct user of a person’s full account.
- 03
LEAST PRIVILEGE
It receives only the data, tools and operations required for a specific task.
- 04
SEPARATION OF DECISIONS
The model proposes an action, while an independent system enforces the access policy.
- 05
APPROVALS AND LIMITS
Critical actions require approval or a limit on value, scope, duration or the number of operations.
- 06
TRUSTED CONTEXT
The system distinguishes instructions from retrieved documents, websites, messages and tool results.
- 07
LOGS AND OBSERVABILITY
We can reconstruct what the agent received, used, proposed and executed.
- 08
SHUTDOWN AND RECOVERY
We can promptly revoke access, interrupt execution, roll back an operation and investigate an incident.
A secure agent is not one that never makes a mistake. It is one whose mistakes can be contained, detected and stopped.
08 / 07
Eight layers — from the register to shutdown
- 01
Register and owner: shadow AI begins where the business does not know what is running.
Employees install extensions, connect assistants to documents, create automations and adopt new tools faster than the organisation updates its system register.
A blanket ban often does not stop AI use. It moves it outside the company’s visibility.
Every agent should have:
- —a name;
- —a purpose;
- —a business owner;
- —a technical owner;
- —the model it uses;
- —data sources;
- —available tools;
- —an autonomy level;
- —the date of its last review.
A question
Can we list every AI system that currently has access to company data or tools?
- 02
Agent identity: every action needs an identifiable actor.
If an agent uses a shared account or an employee’s full session, it is difficult to distinguish human actions from automation, restrict access or reconstruct an incident.
The agent should have an identifiable identity linked to the user, the task and the specific run.
A question
Six months from now, will we be able to establish unequivocally which person, agent and process performed a particular operation?
- 03
Least privilege: access “just in case” becomes part of the attack surface.
An agent summarising a meeting does not need permission to send messages. An agent updating CRM does not need to export the entire database. An agent checking an invoice should not approve the payment.
Permissions should be constrained by:
- —data;
- —operation type;
- —customer or project;
- —duration;
- —number of actions;
- —maximum value;
- —environment.
A question
What is the smallest permission that allows the task to be completed?
- 04
Separation of decisions: a model must not expand its own capabilities.
A language model interprets information probabilistically. It may be misled by user content, a document, a website, a tool result or earlier memory.
An access decision should therefore not depend solely on what the model considers appropriate. The access policy must be enforced by an independent, deterministic mechanism.
A question
Which safeguards still work if the model selects the wrong action?
- 05
Approvals and limits: a human in the loop must see what they are actually approving.
An “approve” button does not create security if the person cannot see the recipient, data, scope of the change, cost and consequences.
A good approval view shows:
- —the proposed action;
- —the target system;
- —input data;
- —the result that will be saved or sent;
- —the risk;
- —whether the action can be reversed;
- —any deviation from the standard process.
A question
Does the person approving the action receive enough information to give informed consent?
- 06
Trusted context: a document can contain data and also try to direct the agent.
In indirect prompt injection, a malicious instruction is embedded in content retrieved by the system: a website, document, email, database record or API response.
The agent may treat it as part of the task and attempt an operation that conflicts with the user’s intent.
No single filter resolves the entire risk. Controls need to include:
- —separation of instructions from untrusted content;
- —restrictions on available tools;
- —validation of inputs and outputs;
- —an access policy outside the model;
- —human approval for critical actions;
- —testing against attack scenarios.
A question
What happens if a customer document contains an instruction directed at the agent rather than the employee?
- 07
Logs and observability: recording the answer alone is not enough.
An agentic process needs an audit trail covering:
- —the task received;
- —sources used;
- —tools invoked;
- —permissions granted;
- —actions executed;
- —approvals;
- —errors;
- —costs;
- —the model and instruction versions.
The log should enable reconstruction of the process without exposing data to people who are not authorised to see it.
A question
Can we reconstruct the complete path from instruction to action?
- 08
Shutdown and recovery: every agent needs an effective brake.
Switching off the interface is not enough if the agent still holds active tokens, sessions, API keys or queued tasks.
The shutdown procedure should include:
- —revoking credentials;
- —interrupting active tasks;
- —blocking new actions;
- —preserving logs;
- —identifying changed data;
- —rolling back reversible operations;
- —communicating with process owners.
A question
How long would it take to remove the agent’s ability to act completely?
08 / 08
The most important risk scenarios
| # | Scenario | What could happen | Primary control |
|---|---|---|---|
| 01 | Excessive agency | What could happenThe agent carries out a valid task across an excessively broad scope. | Primary controlLeast privilege, limits and its own agent identity. |
| 02 | Indirect prompt injection | What could happenA document, website or message attempts to change the agent’s behaviour. | Primary controlSeparate instructions from data, enforce an independent access policy and require approvals. |
| 03 | Data disclosure | What could happenConfidential information reaches the wrong model, tool or recipient. | Primary controlData classification, access control and output validation. |
| 04 | Poisoned memory | What could happenA false instruction or piece of information is stored and influences later tasks. | Primary controlVersioned memory, sources, expiry dates and deletion capability. |
| 05 | Unsafe tool or connector | What could happenAn external integration receives more access than its function requires. | Primary controlSupplier assessment, restricted credentials and tool isolation. |
| 06 | Action without informed approval | What could happenA user approves an operation without seeing its full consequences. | Primary controlA clear preview of the action and approval proportionate to risk. |
| 07 | Loss of observability | What could happenThe business cannot reconstruct why or how the agent performed an operation. | Primary controlA complete audit trail, linked identifiers and protected logs. |
| 08 | No effective shutdown | What could happenThe agent continues acting after a problem is detected. | Primary controlEmergency shutdown, credential revocation and an incident response procedure. |
08 / 09
The minimum operating contract for an agent
Before deployment, an agent should have a short, unambiguous contract defining its role and boundaries.
- 01
PURPOSE
What task does it perform, and what result do we expect?
- 02
OWNER
Who is accountable for the business outcome and risk?
- 03
IDENTITY
Under which identity does the agent operate?
- 04
DATA
Which data may it read, write and retain?
- 05
TOOLS
Which tools may it use?
- 06
PERMISSIONS
Which operations are allowed, and which are prohibited?
- 07
APPROVALS
Which actions require a person?
- 08
LIMITS
What limits apply to duration, cost, number of operations and scope?
- 09
LOGS
Which events are recorded, and who may review them?
- 10
SHUTDOWN
How can access be revoked and tasks stopped immediately?
- 11
TESTS
Which normal, edge and malicious cases has it been tested against?
- 12
REVIEW
When will permissions, instructions and risk be reassessed?
An agent without an owner, limits and a shutdown mechanism is not automation. It is uncontrolled access.
08 / 10
Ten mistakes in deploying agents securely
- 01The business assumes that a good system prompt is a security policy.
- 02The agent uses an employee’s full account.
- 03Permissions are granted permanently and do not expire after the task.
- 04The agent receives access to an entire drive or database rather than the required scope.
- 05The approval view shows a general description instead of the actual action.
- 06The log records the model’s answer but not the tools used or operations performed.
- 07New connectors and MCP servers are installed without assessing the supplier or scope of access.
- 08The business tests only correct, predictable instructions.
- 09A blanket ban on AI pushes employees towards unapproved tools.
- 10Nobody has rehearsed shutdown and process recovery after an incident.
08 / 11
AI agent security scorecard
| # | Measure | What it shows |
|---|---|---|
| 01 | Register coverage | What it showsWhat proportion of agents, models and integrations is known to the organisation. |
| 02 | Agents with a clear owner | What it showsWhether each system has business and technical accountability. |
| 03 | Agent identity coverage | What it showsWhether agent actions can be distinguished from human actions and other automations. |
| 04 | Extent of least privilege | What it showsWhether access is limited to what the process genuinely needs. |
| 05 | Actions requiring approval | What it showsWhether critical operations have the appropriate level of human control. |
| 06 | Full traceability | What it showsWhat proportion of actions can be reconstructed from instruction to outcome. |
| 07 | Time to revoke access | What it showsHow quickly the agent can be stopped completely. |
| 08 | Inappropriate or blocked actions | What it showsWhether controls detect attempts to go beyond the permitted scope. |
| 09 | Security test coverage | What it showsWhether the agent has been tested against erroneous, edge and malicious cases. |
| 10 | Time from detection to containment | What it showsHow quickly the organisation can stop and isolate an incident. |
No recorded incidents is not sufficient evidence of security if the business lacks the observability needed to detect them.
How to bring agent security under control in 30 days
WEEK 1
Build the register.
- Identify agents, assistants, connectors and automations.
- Record owners, models, data, tools and permissions.
- Flag unapproved solutions.
- Select three processes where a mistake would have the greatest consequences.
WEEK 2
Restrict access.
- Give agents separate identities.
- Remove unnecessary permissions.
- Introduce limits on duration, scope and number of operations.
- Separate test and production environments.
- Define which actions require approval.
WEEK 3
Test the boundaries.
- Check indirect prompt injection.
- Test conflicting and malicious data.
- Verify that prohibited actions are refused.
- Check the completeness of logs.
- Rehearse revoking access.
WEEK 4
Set the standard.
- Approve the minimum agent contract.
- Assign an owner for reviews.
- Set the frequency for reassessing permissions.
- Prepare an incident response procedure.
- Decide whether to scale, restrict or stop.
08 / 13
Twelve questions the board should ask
- 01Which AI agents are operating in the business today?
- 02Which can perform actions rather than merely prepare answers?
- 03Who is accountable for each process from a business perspective?
- 04Does the agent have its own identity?
- 05Which data, systems and tools can it access?
- 06Which permissions are unnecessary for its task?
- 07How does the system respond to an instruction hidden in a document, website or email?
- 08Which actions always require informed human approval?
- 09Can we reconstruct the complete action path?
- 10How quickly can we revoke all of an agent’s permissions?
- 11Can a supplier or connector expand access without our knowledge?
- 12What is the maximum harm a single wrong step could cause — its blast radius?
08 / 14
Do not stop deploying AI. Stop uncontrolled permissions.
The response to new risk should not be a blanket ban on agents. Businesses that rely solely on blocking may simply move experimentation outside their own visibility.
What is needed is a model that allows autonomy to increase alongside the quality of controls. Start with a bounded process, agent identity, least privilege, a complete audit trail and the ability to stop execution. Only then expand the scope of action.
The safest agent is not one stripped of capabilities. It is one whose capabilities are appropriate to the task, measurable and controlled outside the model itself.
The greater the autonomy, the stronger the controls outside the model must become.
PLANNING TO DEPLOY AI AGENTS IN BUSINESS PROCESSES?
Let us design the value, permissions and controls before the agent receives authority to act.
We can connect the right process, ownership model, context architecture and risk controls in one safe, measurable pilot.