An AI agent can have an identity. That does not give it authority.

Identity is the foundation, not the final decision

As AI agents gain access to business systems, tools and data, identity is becoming an urgent concern. An organisation needs to know which agent is making a request, which human or service it represents and whether its credentials are genuine.

But identity answers only the first question: who—or what—is asking? It does not, by itself, answer the more consequential question: should this particular action be allowed now?

In February 2026, the US National Institute of Standards and Technology published a draft concept paper on software-agent identity and authorisation. It highlighted the risks created when AI agents are given access to organisational data, applications and tools, and raised questions about identification, authorisation, auditing and non-repudiation. NIST's wider AI Agent Standards Initiative also identifies agent identity and security as important foundations for trusted agentic systems.

This is an essential direction. Organisations must be able to distinguish a legitimate agent from an unauthorised or compromised one. But a valid identity cannot provide unlimited permission.

Consider an AI maintenance agent used by a rail operator. It is authorised to optimise workshop schedules, allocate maintenance bays and rearrange routine tasks to improve fleet availability. The agent identifies a scheduling conflict and proposes deferring a brake inspection that the operator's maintenance policy requires before the vehicle returns to use.

The agent is genuine. Its credentials are valid. Its scheduling objective is legitimate. The proposed action still exceeds its authority.

The organisation remains responsible

The UK Competition and Markets Authority has made the position clear for customer-facing agents: when a business uses an AI agent, the business remains responsible for what that agent does.

Its March 2026 guidance advises organisations to train, test and monitor their agents, maintain appropriate human oversight and respond quickly when an agent is not performing as intended. The wider commercial lesson is straightforward. Delegating a task to an AI agent does not transfer the organisation's responsibility for the consequences.

This makes runtime control more than a technical concern. If an AI agent can take consequential action, the organisation needs a dependable way to apply its own limits when that action is proposed. Policies written in a document or discussed by a governance committee cannot protect operations unless they reach the point where proposed actions become effective.

The National Cyber Security Centre's API guidance supports the underlying principle: apply least privilege, deny by default and validate permissions on every request.

For the rail-maintenance agent, that means evaluating more than its credential.

• Which vehicle and component are affected?
• What change is proposed, and why?
• Which maintenance authority applies?
• Does a qualified engineer need to approve the change?
• Has the proposal materially changed since approval was requested?

Authority needs more than Allow or Deny

A simple permission gate can be too blunt for useful AI. If every unfamiliar action is denied, operators may lose confidence in the system or seek ways around it. If permissions are too broad, an agent may be able to turn an apparently sensible optimisation into an unacceptable operational action.

PF Systems uses five governed outcomes. Allow means a routine scheduling adjustment remains within delegated authority. Deny prevents an action that is not permitted, such as returning the vehicle to service without the required inspection. Modify lets part of the proposal proceed while keeping the inspection in the schedule. Step Up sends a proposed exception to a qualified engineering authority. Stop the Line pauses activity where records conflict, the asset cannot be identified reliably or another critical boundary has been reached.

This preserves more useful choices than unrestricted approval or automatic refusal. The AI agent can continue doing what it does well: finding conflicts, identifying efficiencies and proposing solutions. The organisation retains authority over which proposals may affect the real world.

• Allow
• Deny
• Modify
• Step Up
• Stop the Line

Evidence must follow the action

A decision at runtime is valuable. Evidence of that decision makes it examinable afterwards.

The UK Government's AI Playbook describes accountability in terms that include answerability, auditability and liability. It recommends clear chains of responsibility, traceability and appropriate human oversight for higher-impact uses.

For the maintenance decision, an evidence record should help establish which agent proposed the change, on whose behalf it was operating, which vehicle and inspection were involved, what information was available, which authority applied, what governed outcome was returned and what instruction ultimately became effective.

This is the separation at the heart of PF OS: PF Memory knows. PF Core proves. PF Kernel decides.

PF Memory manages the governed knowledge and context available to the system. It could provide the applicable maintenance requirements, asset context and approved operational information. It does not decide or execute.

PF Kernel applies the organisation's decision authority and returns Allow, Deny, Modify, Step Up or Stop the Line.

PF Core preserves linked evidence and lineage, including the material needed to trace, check and deterministically replay the governed evaluation. This does not make the underlying probabilistic AI deterministic.

Start by observing, not surrendering control

An organisation does not need to begin by placing an unfamiliar governance layer in control of live maintenance operations.

A controlled shadow pilot could observe selected scheduling proposals without changing a work order, releasing a vehicle or actuating any operational system. The operator could compare governed outcomes with decisions made through its existing process and inspect whether the correct context, authority boundaries and evidence were present.

This provides a controlled way to discover which actions require explicit authority, where rules are ambiguous, which decisions should be modified or escalated and whether a production integration should be considered.

Production use would remain a separate decision requiring appropriate technical, operational, security and organisational assurance.

PF Systems does not claim that governance eliminates risk, guarantees safety or automatically establishes compliance. Its proposition is more precise: identity establishes who or what is asking. PF Systems helps organisations govern what that agent may actually do—and preserve evidence of the decision.