How CISOs can secure agentic AI environments without slowing innovation

Unlike conventional software, which executes strict, hard-coded logic within rigid guardrails, artificial intelligence (AI) agents possess autonomy, tool-use capabilities, and natural language understanding.

While these features drive incredible productivity, but they also introduce unique, fast-acting vulnerabilities.

Chief Information Security Officers (CISOs) will also face heightened challenges where organisations allow employees to use AI tools across both company-managed systems and personal devices under bring-your-own-device (BYOD) arrangements.

Unproper configuration of privileged access for agents or lack of measures to prevent sensitive information been fed into AI systems may pose unnecessary risks.

Slowing down AI adoption is not realistic. Instead, CISOs need to set clear limits on what agents can access and do, monitor their actions, and ensure someone is accountable when things go wrong.

Some risk will remain after deployment. What matters is that each known risk has an owner.

Know which agents are operating and what they can do

Start with an inventory of AI agents in use, including those embedded in software-as-a-service platforms, introduced by business teams or accessed through personal devices.

For each agent, identify its business owner, purpose, connected systems, data access, permissions, external destinations and the third-party tools it can call, such as Model Context Protocol (MCP) servers and plugins.

The important distinction is between an AI tool that recommends an action and an agent authorised to carry it out.

Consider an agent that processes supplier invoices. A vendor email contains hidden text instructing it to update the supplier’s bank details.

Without an additional approval check, the agent could make the change using its legitimate access. No malware or stolen credentials would be needed.

A tool that only recommended the change would leave a person to catch the error.

Security reviews must therefore cover the entire workflow, from the inbox to the payment system.

Beyond manipulation, an agent can also become a liability when it is poorly understood. It may make decisions that are difficult to explain afterwards, or accumulate access beyond what was originally intended.

Where resources are limited, start with agents that can act, not just advise.

Protect data and restrict privileges by design

Give agents only the data needed for a defined task, and only for as long as it is needed.

Classification, masking, tokenisation and redaction can reduce what is exposed before data reaches an agent.

Data loss prevention controls should inspect both inputs and outputs, screening for regulated data, secrets such as credentials and API keys, and intellectual property.

Encryption should protect data in transit and at rest; for especially sensitive workloads, confidential computing or other protected execution environments are worth evaluating where available.

Each agent should have a distinct identity, narrowly scoped permissions and an accountable owner, rather than operating invisibly through an employee’s credentials.

Elevated access should require approval, be granted only when needed and expire automatically.

Agents must not be able to grant themselves additional privileges, and every change to their access should leave an audit record.

Approvals for privileged changes should be protected by multi-factor authentication.

Actions should be tiered in advance: routine tasks may run autonomously, while high-impact or irreversible ones, such as changing payment details or deleting records, should require human approval.

BYOD policies need to reflect these rules.

Where a personal device cannot meet an organisation’s security requirements, access to sensitive agent workflows should be limited or channelled through managed applications and protected environments.

That includes controlling where agent credentials are stored and revoking access quickly when a device is lost or compromised.

Make every consequential action traceable

Security teams need to know what an agent accessed, which tools, APIs and identities it used, what actions it took, what decisions or recommendations it produced, and what approvals, overrides and exceptions applied.

If an organisation cannot reconstruct what an agent did, it cannot investigate an incident or show that the agent stayed within its approved boundaries.

Protect logs from tampering and feed them into existing security monitoring and incident response processes, instead of an isolated monitoring silo.

Monitoring should flag unusual data transfers, unexpected destinations, sudden changes in activity, privilege changes and gradual drift away from an agent’s approved purpose.

Dennis Chan, Chief Security Officer at Huawei International, noted that one of the biggest challenges in today's AI development is the "black box" problem, making real-time visibility into agentic workflows, particularly multi-agent orchestration, crucial.

Chan added that Huawei AI developers can leverage tools such as Huawei Cloud's AgentArts to gain end-to-end visibility and real-time observability when building AI agents.

AgentArts uses harness engineering to help turn experimental AI agents into reliable, enterprise-grade production systems by integrating operational controls, continuous monitoring and structured runtime safeguards around autonomous agents.

Prepare employees to recognise and report failures

Often employees may be the first to notice an agent requesting unusual access, reaching into an unfamiliar system, changing information unexpectedly or producing an output that does not match the task.

They need the confidence to treat those signals as potential security incidents, not merely as software glitches.

AI-specific scenarios should be built into awareness programmes and tabletop exercises.

For example, a compromised agent exposing customer information through a personal device, an agent following a malicious instruction hidden in an external document, a productivity tool making unauthorised changes after an integration is altered, and an employee pasting sensitive information into an unapproved public AI service.

Staff need practical instructions on which tools are approved, what information must never be shared with unapproved tools, how to recognise suspicious AI outputs, how to secure personal devices and when to report suspicious behaviour.

Reporting should be straightforward and free from blame.

Autonomy requires accountability

AI agents change the security question from “Can this system be compromised?” to “What could this system do if it were compromised or misled?”

The answer depends less on the model than on the permissions, tools and data around it.

As organisations give software more autonomy, CISOs must help define, before deployment, where that autonomy ends.