Anonymised strategy analysis · Retail · 2026

Agentic AI in retail: when AI agents start taking action

An agentic strategy changes much more than an organisation's conversational interfaces. It reshapes how customers access services, how applications expose business capabilities, and how employees delegate operations. An analysis of a strategy presented by a major retail group in 2026 illustrates these changes and the security decisions they introduce.

Retail is changing its point of entry

From enterprise platforms to agent-driven commerce

Retail has evolved from store-centred operations to omnichannel experiences and then to shared platforms exposing business services, applications and data. Agentic transformation extends that progression: business capabilities become accessible to agents able to coordinate multiple operations in pursuit of an objective.

The change goes beyond employee automation. Customers may increasingly delegate product discovery, comparison and purchase preparation to their own personal agents. Instead of starting on a retailer's website, they could interact with an intermediary that compares suppliers and only contacts the retailer when a service needs to be executed.

The strategy identifies a specific commercial risk: becoming a provider of products, inventory and logistics while an external agent controls recommendations and the customer relationship. Its proposed response has two dimensions: build agentic experiences customers choose directly, and expose business capabilities that external agents can consume.

The organisation does not aim to build every component itself. It seeks to retain control over the assets that differentiate its business: customer knowledge, business rules, contracts governing service access, and information used to learn from interactions and outcomes. Control over these assets becomes as important as control over the customer-facing interface.

A practical example: an assistant for professional purchasing

When an assistant retrieves, recommends and prepares an operation

One demonstration follows a professional purchasing materials for several customer projects. The assistant uses available information about those projects, previous orders and known equipment to identify relevant products, prepare a basket, arrange collection and suggest additional items.

The example matters because advice and execution converge. The agent does not merely generate recommendations: it uses customer context, accesses multiple resources and prepares a business operation. The presentation does not establish a general production rollout or demonstrate that payment is completed autonomously.

Five security decisions behind a seemingly simple journey

Five security decisions behind a seemingly simple journey
Agent actionSecurity question
Retrieve previous ordersWhich order histories can the agent read, and under whose authority?
Use project informationHow is access restricted to the relevant customer's projects and records?
Select productsWhich products, quantities and commercial conditions may be used?
Arrange collectionWho can confirm the operation, and when is human approval required?
Retain contextual informationWhat data can be remembered, reused, corrected or deleted?

These are architectural questions arising from the demonstrated journey, not claims that specific controls have already been deployed by the organisation. They show why a valid application account or a general catalogue permission cannot define the full scope of an agent's authority.

The agent becomes an execution loop

An objective, permissions and verification

The strategy distinguishes a chatbot that answers a request from an agentic system that pursues a goal through a sequence of actions. Its execution framework describes seven stages: define intent, select authorised context, act, retrieve the outcome, verify it, correct the execution when necessary, and preserve useful information in memory.

Every execution loop needs a business owner, explicit permissions and an escalation mechanism. It also needs a reference against which results can be checked, an understanding of its full operating cost, and a record of decisions. The model may participate in execution, but accountability, judgement and sensitive approvals remain human responsibilities.

The strategy identifies a fundamental organisational challenge: companies can build agents faster than they can formalise their own processes. Tacit business rules, local exceptions and informal decisions become problematic when a system is expected to act rather than merely provide advice.

Agentic transformation therefore requires three things to be explicit: what is authoritative, what is permitted and who is accountable. Without this clarity, agents may apply an inappropriate rule or continuously escalate to humans, undermining the value of automation.

Enterprise knowledge becomes infrastructure

Data that agents do not have to interpret arbitrarily

The strategy describes a progression from trustworthy source data to business interfaces that agents can understand. It includes data normalisation, governed data products, consistent indicators, shared business definitions and APIs expressing business capabilities in a clear and reusable way.

The objective is not simply to connect a model to more documents. An agent must be able to distinguish authoritative information from provisional material, understand the meaning of an indicator and recognise the rules governing its use. Without a controlled semantic foundation, a model may combine contradictory information or apply a general policy to an exceptional situation.

Shared memory must remain governed

The envisaged enterprise memory combines current knowledge, documents, decision histories, business relationships and permissions. A knowledge graph connects that information and makes relevant context available across teams, processes and agents.

Shared knowledge also introduces a critical security question. Information available to one employee or team does not automatically become available to every agent because it has entered a common memory system. Access controls must govern retrieval and use before restricted content reaches the model.

Retrieval-augmented generation, persistent memory and document indexes therefore need to preserve the distinction between authoritative sources, derived information and access-restricted content. Knowledge quality and permission enforcement become inseparable requirements.

Industrialise agents without industrialising privileges

Shared foundations instead of isolated agents

The strategy organises transformation around common foundations: knowledge management, an agent execution environment, model access and security. It also includes parallel efforts covering architecture, organisational change and skills. Technical choices are expected to evolve alongside business processes and responsibilities rather than becoming disconnected projects.

The proposed environment combines several complementary functions: a common intake and programme management entry point, a shared context environment, a reusable skills library, tool access through MCP and a gateway for working with multiple AI models. Existing prototypes can become extensions of this environment instead of being discarded.

Shared capabilities reduce duplicated integrations and help teams reuse what others have already built. They also require explicit decisions about which tools are exposed, which agents may call them, what data they can receive and which operations they are authorised to perform. A central tool catalogue is not, by itself, an authorization system.

The strategy also separates AI models, which may be supplied by multiple providers, from enterprise knowledge and rules that the organisation intends to control. The model becomes replaceable, while business context and decision mechanisms remain durable assets.

Agentic transformation is an organisational transformation

Build with business teams and verify outcomes after adoption

The organisation wants cross-functional teams to work from an initial idea through to adoption. Business functions, product teams, designers, architects, developers, data engineers, operations and control functions contribute to a shared outcome instead of handing disconnected deliverables from one department to another.

The prototyping method distinguishes initial exploration with simulated data, validation of a complete user journey with realistic data, and the use of a working prototype as an implementation specification. That final stage may incorporate API contracts and automated tests so that decisions made with users become verifiable technical requirements.

The desired business outcome is defined early and assessed after adoption. The strategy mentions delivery time, effort saved and avoided costs as measurement dimensions, but the source does not provide independently verified results for the demonstrations discussed.

Training supports this change. Employees need to understand AI uses and limitations, managers must learn how to supervise new ways of working, and business specialists must help formalise organisational knowledge. Meaningful agent autonomy depends as much on human practices as it does on model capabilities.

The Ariovis analysis: retain control at the point of action

Identity is necessary, but general permission is not enough

The following principles are Ariovis recommendations derived from the strategy. They do not describe an infrastructure whose deployment has been independently established within the retail group.

The first requirement is to identify the agent, its owner and the mandate under which it operates. When acting on behalf of a user, the relationship between that user, the agent, the task and the duration of delegation must be explicit. Secrets and technical capabilities should be restricted to what the mission genuinely requires.

The second requirement is to evaluate business authorization when an action is requested. A valid OAuth token may allow an API call without describing the precise operations that are appropriate in a particular business context. A fine-grained authorization architecture can evaluate a request using identity, action, resource and context, then enforce that decision through a component on the execution path.

This control must remain independent of the model's preferences. An agent should not be able to bypass a refusal by choosing another interface that exposes the same operation. Policies may also need to consider business relationships, parameters, destinations, volumes, time limits and required approvals.

Comprehensive protection extends beyond the authorization decision

Action-level control must be integrated with broader agent security. Retrieved documents, injected instructions, tools, MCP servers, memories and workloads can influence an agent's behaviour or expose capabilities that exceed its intended mission.

Security mechanisms should discover agents and their dependencies, inspect interactions, constrain dangerous actions, observe execution and respond to behavioural drift. Tracing the sequence from intent to effect helps both incident response and the production of reliable evidence.

These requirements involve distinct but complementary capabilities: IAM for identities and mandates, privileged access management for secrets and elevated capabilities, fine-grained authorization for business decisions, and AI agent protection for tools, data and runtime threats. None should be presented as a universal solution to every agentic security risk.

Reference architecture

  1. User and agent

    Identity, accountable owner, purpose and delegation

  2. Authorised context

    Business sources, RAG, knowledge graph and memory

    Access controls applied before data reaches the model

  3. Tool control point

    Exposed tools, MCP servers, parameters, destinations and restrictions

  4. Authorization decision

    PEP consulting a PDP before the action, using subject, resource, action and context

    Enforcement before the business operation

  5. Business API and operation

    Execution only within the approved scope

  6. Outcome and evidence

    Verification, human approval where required, logging, revocation and remediation

Reference architecture proposed by Ariovis. It illustrates controls to be designed and does not represent a verified deployment within the organisation studied.

Where should an organisation begin?

Choose a business workflow before choosing a technology

An agentic security programme can start with a limited journey: an assistant preparing an order, an agent retrieving documents or a workflow triggering an application operation. The first step is to map the objective, identities, data sources, tools and possible effects.

That map helps distinguish necessary technical access from legitimate business actions, identify human approval requirements, define policies and determine which events should be monitored. The initial scope should be narrow enough to test and representative enough to inform a reusable architecture.

Success is not measured simply by the number of agents deployed. It depends on achieving a business result, applying the right decisions at the right time and explaining what was actually executed. Security makes useful autonomy sustainable rather than replacing it with permanent manual intervention.

Can your AI agents do more than you intend to delegate?

Starting with a real agentic workflow, Ariovis helps you identify the identities, data, tools and sensitive actions involved, then determine the most important security controls. Our approach combines strategic advisory, IAM architecture, fine-grained authorization and AI agent protection according to your actual environment.