AI security changes when software starts to act

Enterprise AI is moving from systems that answer questions to systems that plan, select tools, invoke APIs and complete work. That shift changes the security model. An AI agent is not only another application component. It can become a non-human actor with identity, access, context and authority.

The central question is therefore no longer only whether a model can produce an unsafe output. It is whether the enterprise can control who the agent represents, what it can see, what it is allowed to do, how the action is authorised and what evidence remains afterwards.

Treat enterprise agents like a digital workforce. Give them identity, boundaries, supervision and evidence before you give them autonomy.

From answer engines to action systems

Many organisations still discuss AI security as if the object being secured were a model endpoint. That view becomes incomplete as soon as AI is connected to retrieval systems, memory, tools, business APIs, code repositories, ticketing systems or cloud consoles.

An agent combines a language model with planning, memory, observation and tool use. The benefit is obvious: work completed with less human intervention. The risk is equally important: a failure can move from an incorrect recommendation to an incorrect action.

The agentic AI control plane

A practical control model can be organised around six questions. Together they connect identity, context, policy, execution and evidence into one operating boundary.

01

Identity: who or what is acting?Give every human, application and agent a verifiable identity, and separate user authority from agent authority.

02

Context and data: what can influence the decision?Control the data, memory, retrieval sources and instructions that shape a decision.

03

Policy: what is the agent allowed to do?Define objectives, tools, data classes, limits and approval conditions before execution.

04

Action: what can it execute now?Authorise each sensitive tool call using least privilege, purpose and current risk.

05

Evidence: can we prove what happened?Capture identity, context, decision, action and result so events can be reconstructed.

06

Revocation: how quickly can we stop and recover?Design for fast disablement, credential rotation, rollback and containment.

This is why identity and policy need to sit close to execution. A governance document reviewed quarterly cannot decide whether an agent should send regulated data to an external service right now.

Where enterprise AI controls fail

  • Shadow agents. Agents arrive through developer tools, SaaS features and automation before governance knows they exist.
  • Overprivileged non-human identities. Standing privilege turns prompt manipulation into enterprise action.
  • Context manipulation. Retrieval sources, memory and external content can steer decisions.
  • Tool and API abuse. An answer can be wrong; an action can change a system, send data or modify access.
  • Weak evidence. Without a record of who authorised what, assurance collapses after an incident.
  • Untested recovery. Kill switches and rollback must work before production, not during an incident.

Govern autonomy as a lifecycle, not a checkpoint

Discover where AI operates. Identify the accountable actors. Bound data, tools and purpose. Authorise sensitive actions before they execute. Observe behaviour and drift. Prove what controls actually did. The objective is bounded autonomy: useful AI action with authority, evidence and recovery kept under enterprise control.

Five questions leaders should be able to answer

  • Which AI agents can take actions in our environment today, and who owns them?
  • What data and tools can each agent reach, and is that limited by purpose?
  • Which actions require human approval, and who approved that boundary?
  • Can we reconstruct a high-impact agent decision end to end?
  • Can we stop an agent quickly, and have we tested it?

Production-ready AI should be a control claim

For systems that can reach sensitive information or take meaningful actions, production readiness should include identity, authorisation, data handling, action control, observability, evidence and recovery. The organisation should know what the AI can do, why, who authorised it, what happened when it acted and how to stop it.

Krishna Mohan Parsha

CTO and Co-Founder, Rhinexa

Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.

Follow on LinkedIn

This perspective expands themes first published by the author on LinkedIn.