Your AI Agent Has Credentials, Tools and Autonomy. Can You Prove It Is Under Control?

Artificial intelligence is crossing an important boundary.

For the past several years, most enterprise AI systems have primarily generated content, classifications, summaries or recommendations. A human generally remained responsible for deciding what happened next.

Agentic AI changes that relationship.

An AI agent may be able to search corporate data, call APIs, use administrative tools, access cloud services, create or modify records, send communications, execute code and make decisions in pursuit of an assigned objective.

It can potentially do this continuously and without a human approving every individual action.

That creates enormous opportunities for automation.

It also creates a fundamentally different assurance problem.

On 20 August 2026, the UK National Cyber Security Centre published new interim guidance specifically addressing the cyber risks associated with agentic AI. The guidance recognises that agents may operate with significant autonomy, access production systems and take actions with little or no human intervention. The NCSC recommends safeguards including threat modelling, proportionate autonomy, human oversight, sandboxing, unique agent identities, restricted credentials, monitoring, protected audit logs and the ability to halt agent activity immediately.

The central governance question is therefore no longer simply:

“Is our AI secure?”

It is:

“Can we prove that this autonomous digital actor has only the authority it needs, operates within understood boundaries, is continuously observable and can be stopped when something goes wrong?”

For organisations beginning to deploy agentic AI, that question should be answered before the agent is given access to real systems.

An AI Agent Is Not Just Another Application

Traditional software generally behaves according to explicitly programmed logic.

Give an application a defined input and, within normal operating conditions, its behaviour should be reasonably predictable.

Agentic AI is different.

An agent may be given a goal and determine for itself how to achieve it. It may select tools, construct intermediate tasks, retrieve additional information, interact with other systems and adapt its approach according to what it discovers.

The NCSC describes agentic systems as capable of accessing data sources, remembering context, making decisions, using tools and taking actions in pursuit of a goal. Some systems can also create sub-agents to undertake parts of a task.

That autonomy is precisely what creates value.

It is also what changes the risk.

An instruction such as:

“Resolve outstanding customer account issues.”

could potentially require an agent to read customer records, access billing systems, send emails, alter account information and invoke several external services.

The organisation therefore needs to understand much more than the prompt.

It needs to understand the agent’s entire operational authority.

Credentials Define the Potential Blast Radius

One of the most important points in the NCSC’s new guidance concerns credentials.

Agents should have their own unique identities, distinguishable from humans and other systems. They should have access only to the permissions necessary for the task and, wherever possible, those permissions should be short-lived.

That sounds remarkably similar to established identity and access management principles.

But the implications are different.

A human administrator normally has context, professional judgement, organisational awareness and an understanding that some technically possible actions would be inappropriate.

An AI agent does not possess those characteristics in the same way.

If an agent has:

an OAuth grant;

an API key;

an authenticated browser session;

an SSH credential;

access to a privileged service account;

permission to invoke an administrative API;

then those permissions form part of what the NCSC describes as its potential blast radius.

The important question is therefore not merely:

“What permissions has the agent been given?”

It is:

“What could the agent cause to happen using everything available to it?”

Those are not necessarily the same thing.

An agent with access to a seemingly low-risk API may be able to combine that capability with another tool, data source or credential to produce a consequence that nobody considered when the individual permissions were approved.

Autonomy Should Be a Risk Decision

Not every agent requires the same degree of control.

An AI agent drafting internal meeting notes poses a very different potential impact from one capable of changing firewall rules, responding to security incidents, approving transactions or manipulating production infrastructure.

The NCSC therefore recommends that organisations explicitly consider how much autonomy an agent requires and relate that decision to their risk tolerance and the consequences of failure.

This is significant.

Autonomy becomes a risk decision.

An organisation should be able to explain:

why the agent exists;

what business outcome it supports;

what level of autonomy it has been granted;

why that level of autonomy is necessary;

what the consequences of failure could be;

what outcomes would be unacceptable;

what controls constrain those outcomes;

who accepted the residual risk;

That decision should not disappear into the configuration of an AI platform.

It should form part of the organisation’s assurance record.

Human in the Loop Is Not a Universal Answer

A common response to AI risk is simply to say that a human remains “in the loop”.

But that phrase can conceal enormous variation.

The NCSC distinguishes between:

Human-in-the-loop, where a person approves actions before they occur.

Human-on-the-loop, where the agent operates but humans monitor it and can intervene.

Human-out-of-the-loop, where the system operates autonomously without human review.

The appropriate model depends on consequence.

If an AI system is categorising low-value internal records, post-event review may be sufficient.

If an agent can disable a user account, terminate a production workload, transfer money or modify a security configuration, prior approval may be required.

Even then, the organisation needs evidence that the approval mechanism cannot simply be bypassed.

The important control is not the statement:

“Humans supervise the AI.”

The control is the complete mechanism showing:

which actions require approval → who can approve them → how approval is enforced → what happens if approval is not received → whether the mechanism has been tested.

That is an assurance question.

Prompting Is a Control, But Not the Control

Another important element of the NCSC guidance is that organisations should clearly define what the agent should achieve, what actions it may take and when it must stop and seek human approval.

Organisations should also specify what an agent must not do.

But the NCSC makes an equally important point: organisations should not rely on prompting alone. Technical and operational controls are required to provide defence in depth.

Consider the instruction:

“Never access the production database.”

That may influence agent behaviour.

But compare it with a technical control where the agent’s identity has no network route or credential capable of reaching the production database.

The second is substantially stronger evidence.

This distinction is fundamental to AI assurance.

A policy statement is evidence of intent.

A prompt is evidence of behavioural instruction.

An access-control configuration is evidence of technical enforcement.

A penetration or adversarial test showing that the agent could not circumvent the restriction is evidence that the control has operated under challenge.

Those evidence types should not carry equal assurance weight.

Sandboxing Must Consider Everything the Agent Can Influence

The NCSC recommends running AI agents in sandboxed environments and considering the entire environment the agent can directly or indirectly influence.

That includes:

execution;

networks;

compute;

credentials;

data;

inference infrastructure;

external services;

For higher-risk deployments, stronger isolation should be applied, and network connectivity should generally follow a deny-by-default approach with explicit exceptions.

This again creates a gap between security architecture and security assurance.

An architecture diagram may show a sandbox.

But can the organisation prove:

which network destinations are reachable;

which credentials exist inside the environment;

whether credentials can be extracted;

what host resources are accessible;

whether the agent can invoke unexpected endpoints;

what data is available;

whether sandbox configuration has changed;

whether escape scenarios have been tested;

Simply stating that an agent is sandboxed is not enough.

The organisation needs evidence that the sandbox actually defines and enforces the intended boundary.

Observability Becomes Fundamental

When software operates autonomously, organisations need to be able to reconstruct what happened.

The NCSC recommends reliable telemetry covering agent activity and the surrounding environment, with information retained for both real-time monitoring and subsequent investigation. It also recommends protecting logs against modification or deletion and, where appropriate, making them immutable.

For an agent, useful evidence may include:

the task it was assigned;

relevant instructions and constraints;

model and agent configuration;

tools made available;

tool calls performed;

identities and credentials used;

resources accessed;

network interactions;

approvals requested;

approvals granted or denied;

actions executed;

security alerts generated;

interventions performed;

resulting changes to systems;

This creates an operational evidence trail.

Without it, an organisation may know that something happened without being able to demonstrate why the agent was able to do it.

That becomes particularly important when incidents involve customers, regulated systems or third parties.

On 4 August 2026, the NCSC warned following recent frontier-AI evaluations that strong safeguards, real-time oversight and clear plans for unexpected behaviour are essential, stating that detection after an incident is not sufficient on its own.

The objective therefore cannot simply be forensic reconstruction.

Organisations must combine evidence with active control.

Every Agent Should Have an Assurance Record

As organisations begin operating significant numbers of agents, conventional documentation will struggle to keep pace.

A useful governance model is to create an Agent Assurance Record for each materially autonomous agent.

That record should provide a traceable relationship:

Agent → purpose → autonomy → authority → tools → identity → credentials → data → safeguards → oversight → monitoring → evidence → residual risk

This becomes the agent’s defensible governance position.

It answers questions such as:

Who owns this agent?

Why was it deployed?

What business process is it authorised to perform?

What is it explicitly prohibited from doing?

What systems can it reach?

What data can it access?

What credentials can it use?

What actions require human approval?

What happens if it behaves unexpectedly?

How is it monitored?

How can it be stopped?

When were those controls last tested?

What evidence supports each answer?

And ultimately:

Why does the organisation believe the risk is acceptable?

This Is Where CyConex Provides the Assurance Layer

CyConex is designed to assess evidence against defined security and governance obligations rather than treating a policy statement or questionnaire response as proof.

That model applies naturally to agentic AI.

An organisation could define the security and governance requirements expected of an AI agent using NCSC guidance, the UK AI Cyber Security Code of Practice, internal policies, regulatory frameworks and contractual requirements.

The UK AI Cyber Security Code already establishes lifecycle principles covering risk evaluation, human responsibility, asset management, infrastructure, supply-chain security, documentation of data, models and prompts, testing, monitoring and secure maintenance.

CyConex can then assess the evidence supporting those requirements.

For example:

A policy may state that every agent must use a unique identity.

Identity configuration provides evidence that one exists.

Access-control records demonstrate its permissions.

Architecture evidence identifies where that identity can authenticate.

Technical testing can demonstrate whether privilege boundaries operate as intended.

Operational logs demonstrate how the identity has actually been used.

CyConex can bring those artefacts together and evaluate the resulting evidence against the obligation.

From Green Tick to Evidence Confidence

This is an important difference from conventional compliance tooling.

A governance register might record:

Agent uses least privilege: Yes.

CyConex asks a more useful question:

What evidence demonstrates that least privilege is actually being achieved?

Perhaps the available evidence proves that a dedicated service identity exists but reveals that it has an overly broad cloud role.

The correct conclusion is not simply “compliant” or “non-compliant”.

The evidence may demonstrate that the control is partially achieved, explain precisely why, identify what evidence is missing and recommend the action needed to improve confidence.

That rationale remains linked to the source material and available for human review.

AI assists the assessment.

Humans remain responsible for the assurance decision.

Connect Agent Risk to What the Business Cannot Afford to Lose

The NCSC explicitly links agent autonomy to organisational risk tolerance.

That creates another important opportunity for evidence-based assurance.

An agent should not be assessed only according to its technical architecture.

Its importance depends on what it can affect.

CyConex can place the assessment into organisational context by considering business outcomes, risk appetite and unacceptable losses.

An agent capable of modifying customer records should therefore be considered in relation to:

customer harm;

integrity of regulated information;

operational disruption;

legal obligations;

financial loss;

reputational consequences;

This enables organisations to prioritise assurance effort according to impact rather than applying identical controls indiscriminately to every AI deployment.

Assurance Must Continue After Deployment

Agentic AI will not remain static.

Models change.

Prompts change.

Tools are added.

API permissions change.

Suppliers update services.

New data sources become available.

Agents become more autonomous as organisations gain confidence in them.

A control assessment performed at initial deployment can therefore become obsolete surprisingly quickly.

CyConex supports a model of continuing assurance in which changes to evidence can trigger reassessment and previously accepted conclusions can be challenged when their supporting evidence becomes stale.

This matters particularly for autonomous systems because increasing capability can silently increase risk.

An agent that originally generated recommendations may later be allowed to execute them.

The business process looks similar.

The assurance position is completely different.

Before You Give an Agent Authority, Demand Proof

Agentic AI will almost certainly become a significant part of enterprise technology.

The objective should not be to prevent that transition.

It should be to make autonomy defensible.

The NCSC’s latest guidance provides a clear direction: define what could go wrong, restrict authority, sandbox execution, maintain human accountability, monitor behaviour, preserve evidence and retain the ability to stop the system.

CyConex turns those expectations into an assurance problem that can be systematically assessed.

Not:

“We told the agent not to do that.”

But:

“Here is the control preventing it.”

Not:

“The agent only has limited access.”

But:

“Here is the identity, permission model and evidence showing what it can reach.”

Not:

“A human is responsible.”

But:

“Here is the approval boundary, accountable owner and evidence demonstrating that intervention works.”

Not:

“We monitor the agent.”

But:

“Here is the operational evidence showing what it did, what controls acted and what happened when it crossed a threshold.”

As AI systems gain tools, credentials and autonomy, trust cannot rest on the behaviour organisations hope they will exhibit.

It must rest on controls whose effectiveness can be demonstrated.

Before an organisation gives an AI agent the authority to act, it should be able to prove exactly where that authority begins, where it ends—and what will stop the agent if it crosses the line.