Learning to Connect

1. From screens to intent

   People say what they want. The agent finds, compares and acts across channels for them.

   • Intent
   • Comparison
   • Action

2. A machine is the visitor

   The agent reads products, prices and services through machine interfaces, not through pages.

   Explored in How interactions shift

   • Machine-readable
   • APIs
   • Protocols

3. Who owns the relationship

   The agent sits between customer and business, so trust, ranking and access decide who gets chosen.

   Explored in Who controls access

   • Trust
   • Ranking
   • Access

1. Describe what you offer

   Products, services, prices and conditions as clean, current data an agent can read.

   • Product data
   • Service catalog
   • Conditions

2. Open the right doors

   Business services through APIs and agent protocols, each with a clear owner.

   Explored in Digital & AI Integration

   • APIs
   • MCP servers
   • UCP

3. Know who is acting

   Recognise the agent, the person behind it and the mandate it carries.

   Explored in Identity & Access

   • Agent identity
   • Mandate
   • Consent

4. One journey across channels

   Hand over between agent, app, site and person without starting again.

   • Handover
   • Shared context
   • Route to a person

5. Measure the agent channel

   Track agent traffic, conversion and complaints as a channel of its own.

   • Agent traffic
   • Conversion
   • Quality

1. Strategic core

   Strategy, ecosystem and value, tied to company objectives and key results. The question: is this worth doing?

   • Objectives
   • Ecosystem
   • Value

2. Lifecycle

   Discover, design, build and scale, in short iterations. From ambition to a working, evaluated agent.

   • Discover
   • Design
   • Build
   • Scale

3. Shared foundation

   Security, data platforms and agent operations that every team reuses, across industries.

   • Security
   • Data platform
   • AgentOps

1. Start from the outcome

   Define the result first, then ask how the process would work if agents could gather information, reason and act.

   • Outcome
   • Future process

2. Automate, assist or keep human

   Decide per task: fully automated, agent-assisted or reserved for people. A new process doesn't mean delegating every decision.

   • Automate
   • Assist
   • Human

3. Divide the work

   Agents take the repetitive, data-heavy work; people keep judgement, creativity and relationships.

   • Repetitive work
   • Judgement
   • Relationships

1. Four value levers

   Efficiency, cost, customer experience and revenue. Each use case needs its own measure of success.

   • Efficiency
   • Cost
   • Customer experience
   • Revenue

2. Impact versus feasibility

   Smart wins first: high impact and feasible with today's data and APIs. Strategic bets next; drop what is low on both.

   • Smart wins
   • Strategic bets
   • Improvements

3. RICE

   Reach × impact × confidence ÷ effort. Confidence includes how predictably the agent behaves. A score makes assumptions visible, not objective.

   • Reach
   • Impact
   • Confidence
   • Effort

4. MoSCoW

   Must, should, could, won't: keep the scope honest. A high score never removes a required guardrail.

   • Must
   • Should
   • Could
   • Won't

1. User, goal, tasks

   Who is it for, what do they want to achieve, and which tasks get them there? Agent capabilities follow from the tasks.

   • User
   • Goal
   • Tasks

2. Beyond the happy path

   Plan for missing products, conflicting wishes, budget breaches and a failed checkout. Show where people can check, change or stop the agent.

   • Edge cases
   • Approval
   • Stop

3. Prototype first

   Test the key assumption with a prototype before production work.

   • Prototype
   • Validate

1. Soul

   Who the agent is: its role, values, tone and hard limits.

   • Role
   • Values
   • Boundaries

2. Memory

   What it keeps across conversations: facts, preferences and past work. Govern it like data: record its source and validity, allow correction and deletion, and verify it before trusting it.

   • Working context
   • Long-term memory
   • Knowledge

3. Skills

   Know-how it loads only when a task needs it: procedures, tools and checks.

   • Procedures
   • Tool use
   • Checklists

1. Start small and focused

   One clear goal per agent and a visible benefit, then grow step by step. Use several agents only when one is not enough.

   • Single agent
   • Multi-agent when needed

2. People stay in charge

   Approval for high-impact actions, and a way to override or stop the agent.

   • Human in the loop
   • Approval
   • Override

3. Limits in the system, not the prompt

   An order above the agreed limit goes to a person. Enforce limits in the application or tool, not only in instructions.

   • Guardrails
   • Action limits

1. Evaluate continuously

   Golden examples, a fixed method, a regular rhythm and alerts when quality drops. Logs and dashboards link agent behaviour to business results.

   • Golden datasets
   • Evaluation
   • Monitoring
   • Dashboards

2. Measure the whole workflow

   Compare outcomes with the current way of working: service quality, time, cost, human review, exceptions and recovery, not just usage or hours saved.

   • Outcomes
   • Baseline
   • Human review

3. Re-evaluate after every change

   Behaviour shifts with models, data, prompts and tools. Agree in advance what triggers a new evaluation or approval.

   • Drift
   • Change control
   • Re-approval

4. Foundations that scale

   Managed agent identities, least-privileged access, modular components and trusted enterprise data, from the start.

   • Agent identity
   • Least privilege
   • Trusted data

Task sizing

Give each task a clear outcome, manageable scope and acceptance checks.

Agent customization

Set reusable instructions for the repository, team and kind of work.

Try and try again, but eventually stop

Retry with new evidence, within explicit attempt, time and cost limits. Stop and ask when those limits are reached.

Packaged skills

Package repeatable procedures with examples and checks.

AI-augmented debugging

Use agents to form hypotheses and investigate; reproduce the issue and test the fix.

Few-shot prompting

Show representative examples of the expected change or output.

Cross-agent verification

Ask another agent to challenge the work, then verify it with tests and human review. Agreement alone is not proof.

Environmental sandboxing

Constrain execution and access in a safe, task-appropriate environment.

Spec-driven development

Make intent, constraints and acceptance criteria explicit before implementation.

Plan mode

Review the approach before authorising changes.

Async development

Let bounded work progress separately, with clear handovers and review points.

Vibe coding

Explore ideas conversationally; production readiness still requires engineering checks.

Remote agent execution

Run work in a controlled remote environment with scoped access.

Multiple modes of interaction

Move between conversation, editor, terminal and review as the task needs.

Event triggered coding

Start scoped work from an issue, event or check; a trigger is not permission to release.

Structured markdown

Keep requirements, conventions and task context in readable, organised files.

Architectural context

Explain boundaries, dependencies and design decisions, not just individual files.

MCP tools

Connect relevant tools and data with explicit access controls; the protocol alone does not make access safe.

Multi-model prompting

Use different models where useful, preserving the same task context and checks.

Agent event hooks

Attach controlled checks or context updates to lifecycle events.

Design-to-code

Bring design intent, component rules and visual references into implementation.

Long running agents

Let agents work across longer tasks with checkpoints and a defined finish.

Forced long running agent loops

Continue deliberately only while acceptance checks remain unmet, within explicit iteration, time and cost budgets. Stop on completion, a blocker or any safety limit; never bypass safeguards.

Subagent delegation

Delegate bounded work with inputs, ownership and a verifiable handover.

Role-scoped agents

Give each agent a defined responsibility and permission boundary.

Task-scoped agents

Create focused agents for a specific deliverable, then close the task.

Non-deterministic agent roles

Select or adapt roles as the work evolves, while keeping ownership and controls explicit.

Commit context summary

Record concise rationale, decisions and verification with the change, not private internal reasoning.

User-selected agent modes

Let people choose how much the agent may do and when review is required.

Distinct agent permission scopes

Separate read, edit, execute and release permissions by role and task.

Model cost management

Choose suitable models, set budgets and monitor usage; stop or escalate at agreed limits.

Workspace isolation

Keep parallel work and its dependencies separate to avoid unintended interference.

1. From where to how

   E-commerce changed where people shop; agentic commerce changes how. Shopping shifts from an active task to a background process.

   • Search
   • Compare
   • Purchase

2. Acting when you're not there

   Agents give advice and decide on someone's behalf, enter payment details and can buy when that person is not present. The benefits grow with autonomy, and so do the risks.

   • Advice & decisions
   • Payment details
   • Unattended purchases

3. Automate the routine

   Agents fit best where criteria are objective and easy to compare: repeat, replacement and standardised purchases, bought at the right moment from usage patterns.

   • Repeat purchases
   • Replacement
   • Standardised products

4. Taste stays human

   In fashion, home and luxury, agents pre-select and support the decision; people keep the final say.

   • Decision support
   • Pre-selection

1. Integrated ecosystems have the edge

   Whoever combines assortment, data, payments and logistics can put agents to work fastest, and gains influence over the customer.

   • Assortment
   • Data
   • Payments
   • Logistics

2. Agents are rarely neutral

   Embedded in commercial ecosystems, agents shape product choice and control access to customers. That is why transparency and choice matter.

   • Gatekeepers
   • Ranking
   • Access

3. Open access, clear roles

   Platforms can steer checkout, payment methods and loyalty, or limit which agents get in. Open access without unreasonable restrictions, and a clear merchant of record, keep the market fair.

   • Checkout
   • Merchant of record
   • Open access

1. Any payment rail

   Agentic commerce runs on cards, account-to-account and tokenised money, through agent providers, schemes, wallets, issuers and acquirers.

   • Cards
   • Account-to-account
   • Tokenised money

2. Data to fight fraud

   To prevent scams and settle disputes, the payment chain needs agent identity, merchant of record, intent and purchase details, with consent.

   • Agent identity
   • Intent
   • Disputes

3. Liability follows the risk

   People can see and manage what they delegate. When something goes wrong, every party in the chain works on the dispute, and liability lands where the risk or error was introduced.

   • Delegation
   • Authentication
   • Liability

4. Protocols, standards, policies

   Three ways to agree: protocols set the technical rules for interaction, standards the shared conventions and requirements, policies how the ecosystem is governed.

   • Protocols
   • Standards
   • Policies

5. Stores beyond sales

   Physical stores move from sales channel to a place for advice, service, inspiration and support of online sales. Give each store a clear role, connect it to the digital channels, and add value where automation can't.

   • Advice
   • Service
   • Inspiration
   • Omnichannel

1. A permission dashboard

   Customers see and manage every permission they have given to access their data, in one place.

   • Dashboard
   • Revocation
   • Transparency

2. No obstacles to access

   The rules list the obstacles a bank may not put in the way of authorised providers.

   • Prohibited obstacles
   • Non-discrimination
   • Dedicated interface

3. Stronger fraud prevention

   Payment providers check that the payee's name matches the account, offer spending limits and carry the loss when their prevention fails.

   • Payee name check
   • Spending limits
   • Impersonation fraud

4. Fair access for payment firms

   Banks give payment institutions access to payment accounts on a non-discriminatory basis.

   • Level playing field
   • Account access

Source European Parliament, payment services deal, 27 November 2025

1. Premium APIs

   Banks offer more than the legal minimum, under contract and for a fee: richer data, higher limits and new services.

   Explored in Developer & Agent Experience

   • Contracts
   • Service levels
   • Pricing

2. Market schemes

   The SEPA Payment Account Access scheme of the European Payments Council sets shared rules for these premium services.

   • SPAA
   • European Payments Council
   • Shared rules

3. Common standards

   Shared API standards keep the integration cheap for every bank and every provider.

   Explored in Manifesto

   • Berlin Group NextGenPSD2
   • STET
   • OpenAPI

Source European Payments Council, SPAA scheme

1. Permission becomes a mandate

   The customer gives an agent a scoped, time-bound and revocable mandate, and sees and manages it in one place.

   Explored in Act on someone's behalf

   • Mandate
   • Scope
   • Expiry

2. Authentication stays with the provider

   The agent never holds the customer's credentials. The company that holds the account still authenticates the customer and asks for approval.

   Explored in Authenticate

   • Strong authentication
   • Approval
   • No shared credentials

3. Know which agent calls

   Every call names the platform, the agent and the customer it acts for.

   Explored in Govern the agents

   • Agent identity
   • On behalf of
   • Audit trail

4. The same rules in every channel

   App, website, partner and agent get the same limits, fraud checks and proof of what the customer approved.

   Explored in The payment chain

   • Fraud checks
   • Limits
   • Evidence

1. Many alliances fall short

   Between 30 and 70 percent of alliances fail, research finds, most often through economic tension and social conflict between the partners.

   • Alliances
   • Failure rate

2. Four sources of tension

   Disappointing financial results, weak mutual trust, high investments that only pay off inside the partnership, and no alternative partner.

   • Results
   • Trust
   • Lock-in

3. The response decides

   How a partner responds to tension decides whether the partnership survives. Responses are often chosen without thinking about what they set off.

   • Response strategy

1. It started with people

   Exit, voice and loyalty were first described for people responding to decline in firms, organisations and states. Neglect was added from research on romantic relationships and on how employees respond to dissatisfaction at work.

   • Exit
   • Voice
   • Loyalty
   • Neglect

2. Colleagues and teams

   I read the same seven responses between colleagues, in teams and with a manager: the plan pushed through every meeting, the silence in a stand-up, quietly looking elsewhere. Read them the same way.

   • Teams
   • Leadership
   • Feedback

3. Between agents too

   As agents act for firms, they meet each other and the people around them. I expect the same seven responses there: an agent that stops answering, one that holds back information or games the rules, one that pushes its own outcome, one that proposes a better way. The circle gives you something to design for: which responses an agent may choose, when it must hand over to a person, and which signals count as early warning. Untested so far; the research covers people at firms.

   • Agents
   • Handover
   • Early warning

1. Your response shapes theirs

   Foresee what your own response will set off, and change it to steer theirs. Only an active, constructive response stops a slide towards the end.

   • Steer
   • Anticipate

2. Talk about how you work together

   Address disagreement in the shared way of working, not the person. Accusations only make the relationship worse.

   • Metacommunication

3. Look at yourself

   Look for the cause of a partner's response in your own actions, and change your own behaviour.

   • Self-reflection

4. Contracts set the rules, responses decide

   Open banking, platforms and agent ecosystems depend on partners who keep responding constructively when tension comes.

   Explored in Business Channels · Open Finance · Developer relations

   • Ecosystems
   • Partners

1. Seven distinct responses, one order

   A survey of alliance managers at Dutch firms showed that the seven responses are distinct, and a circumplex analysis confirmed their order on the circle.

   • Factor analysis
   • Circumplex analysis

2. The same circle across cultures

   Research in the Netherlands, Switzerland, Turkey and Japan found that what the responses are and how they relate is nearly universal, while the responses people prefer differ by culture.

   • Culture
   • Countries

Publications

1. 2016

   National Cultures and Response Strategies in Strategic Alliances: Cultural Universalism or Cultural Relativism?

   Olivier Furrer, Brian Tjemkes and Koen Adolfs

   Governance Issues in Strategic Alliances, ed. T.K. Das, pages 173 to 200

2. 2012

   Responding to Adverse Situations Within Exchange Relationships: The Cross-Cultural Validity of a Circumplex Model

   Olivier Furrer, Brian Tjemkes, Arzu Ülgen Aydinlik and Koen Adolfs

   Journal of Cross-Cultural Psychology 43(6), pages 943 to 966

3. 2012

   Response strategies in an international strategic alliance experimental context: Cross-country differences

   Brian Tjemkes, Olivier Furrer, Koen Adolfs and Arzu Ülgen Aydinlik

   Journal of International Management 18(1), pages 66 to 84

4. 2011

   Alliantiemanagement: Een responsstrategietypologie

   Koen Adolfs, Brian Tjemkes and Olivier Furrer

   Management & Organisatie, issue 5

5. 2009

   Cross cultural differences in responding to adverse situations in strategic alliances

   Presented at the Academy of Management Annual Meeting, Chicago

1. Boosts business

   A digital ecosystem for internal, partner and public solutions.

   • Unleash creativity
   • Higher velocity

2. Untangles IT

   A modular and flexible IT landscape.

   • Easier to change
   • Lower risks
   • Future proof

3. Streamlines cooperation

   Create once, reusable by all.

   • One stop shop
   • Focus on the customer journey
   • Clear responsibilities
   • Increased team autonomy

1. Functionality-centric

   Ask a system to do something, now. MCP tools bring this style to agents.

   Explored in API styles · Resource modelling · Service oriented architecture · How MCP works

   • APIs
   • REST
   • GraphQL
   • gRPC
   • API gateways
   • Process orchestration
   • Request/reply
   • Polling
   • Callback
   • Streaming
   • MCP tools

2. Event-centric

   React when something happens. Webhooks and open connections push the change; MCP servers announce when their tools change.

   Explored in API styles · Beyond request and response

   • Events
   • Streaming
   • Webhooks
   • WebSockets
   • Publish / subscribe
   • Change data capture
   • MCP notifications

3. Data-centric

   Move and share data at scale. Agents read it as MCP resources, under the same rules.

   Explored in Ways to share data · Data for agents

   • Batch
   • File transfer
   • ETL
   • Data products
   • Data virtualisation
   • MCP resources

1. How it works

   Consumers never call systems directly: they call services through the integration layer. Domains keep their own logic and data and expose business functionality. Each domain can have its own canonical model, so domains change at their own pace.

   • Services
   • API gateway
   • External API gateway
   • Service bus for legacy
   • Decentralised domains
   • Multiple canonical models

2. Three ways to connect

   A straight connection when no transformation is needed. A transformation component when a legacy system or integration requirement sits in between. An API gateway when an internal provider serves an external consumer.

   • Direct
   • Legacy decoupling
   • External exposure

3. Principles

   Business functionality is exposed as services, so applications can change without everything else changing. Data coupling stays, because services still need each other's data.

   • Optimise close to the data
   • Expose functionality, not systems
   • Keep domain logic in your domain
   • Build services for the consumers
   • Simplicity and modern community standards
   • Business meaningful over re-usable

4. Beyond request and response

   Service orientation leans on request and response. Streaming suits high volumes, real-time needs and many consumers: a change creates an event, a streaming platform distributes it, and new streams can be filtered or combined from existing ones.

   • Event streams
   • Publish / subscribe
   • CQRS
   • Replay
   • Reactive architecture

1. Private

   Inside one application only, not reusable. Ungoverned, it becomes a shadow API.

   • Governed
   • Ungoverned (risk)

2. Internal

   Reusable across the organisation, found on the internal API portal.

   • Enterprise
   • Third party
   • Business meaningful
   • Reusable
   • Loose coupling

3. Open

   For partners, customers and the public, on the developer portal.

   • Partner
   • Service provider (with consent)
   • Customer
   • Public

4. Earning model

   Who pays whom for an open API.

   • Free
   • Developer pays
   • Developer gets paid
   • Indirect

1. Start from the consumer

   Translate consumer requirements into the operations they need, then talk the list through with them. Gaps and overlaps show up here: consumers may also need to block a current account, not only create, read and end one.

   • Who are the consumers?
   • What do they need?
   • Which business processes?
   • Which granularity?

2. Resource

   The core of a REST API. Its name returns in the API name and the URL, so it must be clear and descriptive. A data resource can be stored, such as CurrentAccount. A process resource triggers a process, such as CustomerOnboardingRequest. An action resource executes an action, such as CreditCardEligibilityCheck.

   • Data resource
   • Process resource
   • Action resource

3. HTTP verb

   Choose by two questions: is the operation safe, and is it idempotent? A GET never changes the resource, which makes it cacheable and safe to prefetch.

   • GET
   • POST
   • PUT
   • PATCH
   • DELETE
   • Safe
   • Idempotent

4. Sub-resource

   Isolate a part of a resource when it needs its own operation or its own authorisation, such as blocking a debit card.

   • Own operation
   • Own authorisation

5. Identifier

   Every data resource needs one, normally based on the golden source of the data. It is optional for sub-resources and for process and action resources.

   • Golden source

6. URL

   Largely derived from the resources. Self-explanatory, easy to build clients against, and unique today and in future.

   • Unique
   • Self-explanatory

7. One central model

   All resource models sit in one central model. That keeps ownership clear, avoids duplicate or overlapping APIs, and keeps every URL unique. A competence centre reviews each model for coherence, consistent naming and future name collisions.

   • Central model
   • Clear ownership
   • Review

1. 1. Local application

   Remote procedure calls in a compact binary format.

   • RPC
   • Binary format

2. 2. Web application

   SOAP with XML files.

   • SOAP
   • XML

3. 3. Web, app & chatbots

   Learn each API separately: by the developer, pre-defined.

   • REST
   • JSON
   • General-purpose, software to software
   • No self-discovery for AI
   • Different authentication schemes
   • Breaks if the API changes
   • Custom code for each API

4. 4. AI agents

   Learn once, use everywhere: by the agent, at runtime.

   • MCP
   • A2A
   • AI native, designed for LLMs
   • Self-describing capabilities
   • One protocol for all servers
   • Adapts to changes at runtime
   • Easier AI integration with adapters

1. Discovery & interaction

   How do agents connect and interact?

   • MCP
   • A2A
   • WebMCP
   • MCP Apps
   • A2UI

2. Identity & trust

   Who is the agent, and why accept it?

   • Visa TAP
   • ERC-8004

3. Intent & delegation

   Who acts for whom, and with what scope?

   • Poppy / PAP
   • AP2

4. Commerce coordination

   How are orders and paid resources coordinated?

   • UCP
   • ACP
   • MPP
   • x402

5. Evidence & disputes

   What can we prove about intent and execution?

   • A-Comm AEP

1. Master & reference

   The core records everyone relies on: customers, products, locations and codes. One golden source each.

   • Golden source
   • Master data
   • Reference data

2. Transactions & events

   What happened and when: orders, payments and changes. Captured once, published as events.

   • Transactions
   • Events
   • Change data capture

3. Analytical

   History shaped for insight and models, in open table formats.

   • Data warehouse
   • Lakehouse
   • Open table formats

4. Documents & content

   Contracts, emails, policies and images: most knowledge is unstructured.

   • Documents
   • Content
   • Metadata

5. Knowledge for AI

   Meaning made explicit: definitions, relations and embeddings that agents can search.

   • Semantic layer
   • Knowledge graph
   • Vector index

1. Batch & files

   Large volumes on a schedule, when minutes or hours are fine.

   • Batch
   • File transfer
   • ETL

2. Streams

   Changes as they happen, for many consumers at once.

   Explored in Beyond request and response

   • Event streaming
   • Change data capture
   • Replay

3. Data services

   Query a governed interface instead of copying the data.

   • Data APIs
   • Virtualisation
   • Query federation

4. Shared tables

   One copy in an open format, read by many engines.

   • Open table formats
   • Zero copy
   • Data sharing

1. Retrieval

   Agents answer from current, permitted sources, and show where each answer came from.

   • Retrieval-augmented generation
   • Citations
   • Permissions

2. Shared meaning

   A semantic layer gives every metric and term one definition, for people and agents alike.

   • Semantic layer
   • Metrics
   • Glossary

3. Relations

   A knowledge graph connects customers, products and processes, so agents can reason across them.

   • Knowledge graph
   • Entities
   • Relations

4. Through protocols

   Agents reach data as resources and tools on MCP servers, and the server applies the same access rules as for any other consumer.

   Explored in How MCP works

   • MCP resources
   • Data APIs
   • Access rules

5. Memory is data

   What an agent remembers is governed like data: source, validity, correction and deletion.

   Explored in Soul, memory & skills

   • Agent memory
   • Provenance
   • Deletion

1. Catalog & lineage

   Know what exists, what it means, where it comes from and who owns it.

   • Data catalog
   • Lineage
   • Ownership

2. Quality

   Agreed checks on completeness, accuracy and freshness, with alerts when they fail.

   • Data contracts
   • Quality checks
   • Observability

3. Classification & privacy

   Label sensitive data once; access, masking and logging follow the label.

   • Classification
   • Masking
   • Privacy by design

4. Consent & purpose

   Use data only for the purpose people agreed to, and keep the proof.

   • Consent
   • Purpose limitation
   • Audit trail

5. Retention & deletion

   Keep data as long as needed, then delete it everywhere, including copies and indexes.

   • Retention
   • Deletion
   • Right to erasure

1. One identity per actor

   Every person, agent and service has its own identity. No shared accounts, no borrowed credentials.

   • Unique identity
   • No shared accounts

2. Least privilege

   Only the access a task needs, for only as long as it needs it.

   • Least privilege
   • Just in time
   • Short-lived

3. Verify every request

   Trust no network or session by default: check identity, device and context each time.

   • Zero trust
   • Context
   • Continuous verification

4. Explicit consent

   People see and control what they share, and whom they let act for them.

   • Consent
   • Transparency
   • Revocation

5. Separate proof and permission

   Identity proves who is calling; a separate decision grants what it may do.

   • Authentication
   • Authorisation
   • Policy

1. Passwordless

   Passkeys bound to a device replace passwords and resist phishing.

   • Passkeys
   • FIDO2
   • WebAuthn

2. Step up on risk

   Ask for a stronger check only when the action or the context calls for it.

   • Multi-factor
   • Risk-based
   • Step-up

3. Single sign-on & federation

   One sign-in across applications and partners, through open standards.

   • OpenID Connect
   • SAML
   • Federation

4. Digital identity wallets

   People share verified attributes from a wallet, and only what is needed.

   • Verifiable credentials
   • EUDI Wallet
   • Selective disclosure

5. Workloads & agents

   Software proves who it is with certificates or signed tokens, never with a stored password.

   • Workload identity
   • SPIFFE
   • Mutual TLS

1. Tokens & scopes

   Access tokens carry exactly what a client may do, and expire quickly.

   • OAuth 2.1
   • Scopes
   • Short-lived tokens

2. Roles, attributes, relationships

   Combine role, attributes and relations to decide access in context.

   • RBAC
   • ABAC
   • ReBAC

3. Policy as code

   One central policy, enforced at every gateway, service and tool.

   • Policy engine
   • Gateways
   • Enforcement points

4. Fine-grained

   Decide per resource and per action, down to a single account or document.

   • Resource level
   • Action level

1. Joiner, mover, leaver

   Access follows people automatically when they start, change roles and leave.

   • Joiner
   • Mover
   • Leaver

2. Provisioning

   Accounts and rights flow from one source to every application through open standards.

   • SCIM
   • Provisioning
   • Single source

3. Access reviews

   Owners regularly confirm who has access to what, and remove what is no longer needed.

   • Recertification
   • Owners
   • Clean-up

4. Non-human identities

   Service accounts, keys and agents get an owner, rotation and an end date, just like people.

   Explored in Govern the agents

   • Non-human identities
   • Secret rotation
   • Agent registry

5. Detect and respond

   Watch for unusual sign-ins and access, and act on them fast.

   • Threat detection
   • Session revocation
   • Audit trail

1. Know your agents

   A registry of every agent: owner, purpose, status and review date. Register, change, suspend and retire each one; when an agent retires, its access and open tasks are handed over.

   • Agent registry
   • Clear ownership
   • Lifecycle

2. Give each its own identity

   Every person, agent and service gets its own identity and least-privilege rights. Identity proves who is calling; a mandate proves what it may do, and stays scoped, traceable and revocable while the agent works.

   • Non-human identities
   • Least privilege
   • Short-lived credentials

3. Control what they reach

   A catalog and gateway decide which data and tools an agent may use.

   • Data & tool catalog
   • Gateway
   • Policies

4. Set its bounds

   Decide per agent what it may do alone, what needs approval and when it must stop and escalate. Only its owner can widen the bounds.

   • Autonomy bounds
   • Approval
   • Escalation

5. Watch and account

   See what agents do and what they cost.

   • Observability
   • Audit trail
   • Cost attribution

1. Business layer

   Who may decide and approve?

   • Human approval for high-impact actions
   • An owner per agent
   • Consent & delegated authority
   • Transaction limits

2. Agentic layer

   How does the agent behave?

   • Treat all input as untrusted
   • Input & output guardrails
   • Isolated memory
   • Step, cost & retry limits
   • Red teaming before release

3. Data & integration layer

   What may it reach, and as whom?

   • Own identity per agent
   • Least-privilege, scoped tools
   • Short-lived credentials
   • Gateway & policy enforcement
   • Signed agent-to-agent messages

4. Platform layer

   Where does it run, and can we stop it?

   • Sandboxed execution
   • Secrets management
   • Logging & tracing
   • Agent inventory (AgBOM)
   • Kill switch

Measures drawn from OWASP's agent security guidance.

1. AI Act

   Obligations follow the risk: some uses are banned, high-risk systems need risk management, data governance, logging and human oversight, and people must know when they deal with AI.

   • Risk-based
   • Human oversight
   • Transparency

2. GDPR

   Personal data needs a lawful basis and a clear purpose, only what is needed, and people can contest decisions made solely by automated means.

   Explored in Govern by design

   • Lawful basis
   • Data minimisation
   • Automated decisions

3. DORA

   Financial firms manage ICT risk, report major incidents, test their resilience and keep control of critical third-party providers, exit plans included.

   Explored in Platform & Operations

   • ICT risk
   • Incident reporting
   • Third-party risk

4. PSD2, PSR and PSD3

   Strong customer authentication, open access to payment accounts and shared responsibility for fraud.

   Explored in Open Finance

   • Strong customer authentication
   • Account access
   • Fraud

5. eIDAS 2

   European Digital Identity Wallets, which regulated services such as banks must accept where they require strong user authentication.

   Explored in Authenticate

   • EUDI Wallet
   • Verified attributes
   • Strong authentication

Source AI Act · GDPR · DORA · PSD2 · eIDAS 2

1. Know the risks

   What can go wrong?

   • OWASP Top 10 for Agentic Applications 2026
   • OWASP Top 10 for LLM Applications 2026
   • OWASP API Security Top 10
   • OWASP MCP Top 10
   • OWASP Non-Human Identities Top 10

2. Design it safely

   How do we build agents securely?

   • OWASP Agentic AI Threats & Mitigations
   • OWASP Securing Agentic Applications Guide
   • OWASP AI Exchange
   • OWASP AI Agent Security Cheat Sheet
   • OWASP MCP Security Cheat Sheet

3. Verify and control

   How do we prove it holds?

   • OWASP ASVS 5.0
   • OWASP AISVS
   • OWASP AI Testing Guide
   • OWASP GenAI Red Teaming Manual
   • OWASP Agent Control Standard

4. Govern

   Who decides and who is accountable?

   • OWASP LLM Cybersecurity & Governance Checklist
   • OWASP GenAI Security Framework Crosswalk

5. Public standards & regulation

   What do standards and law expect?

   • EU AI Act
   • DORA
   • ISO/IEC 42001
   • ISO/IEC 27090
   • NIST AI RMF
   • MITRE ATLAS

1. A portfolio, not one model

   Large models for open reasoning, small models for routine and high-volume work, specialised models for code, speech or images.

   • Frontier models
   • Small models
   • Specialised models

2. Route on purpose

   A gateway picks the model per request by quality, cost, speed and data sensitivity, and switches when a provider fails.

   Explored in One gateway per kind of traffic

   • AI gateway
   • Routing
   • Fallback

3. Open and closed

   Open-weight models run where you choose; proprietary models bring the frontier. Both sit behind the same interface.

   • Open weights
   • Proprietary
   • One interface

4. Test before you switch

   A new model is a release: try it on your own cases before it serves a customer.

   Explored in Scale: quality and alignment

   • Evaluation sets
   • Regression tests
   • Release gates

1. Public cloud

   Fast access to the newest models and capacity that grows with demand.

   • Managed models
   • Elastic
   • Pay per use

2. Private and sovereign

   Sensitive data and critical processes on infrastructure you control, in the jurisdiction you choose.

   • Data residency
   • Sovereignty
   • Own keys

3. Local and edge

   Small models on devices and sites, for privacy, speed and working offline.

   • On device
   • Low latency
   • Offline

4. An exit plan

   Know how to move every workload to another provider, and test that you can.

   Explored in Regulation in one view

   • Portability
   • Exit strategy
   • Concentration risk

1. Trace every step

   Follow one request through agents, tools, models and APIs in a single trace.

   • OpenTelemetry
   • Tracing
   • Correlation

2. Watch quality in production

   Sample real interactions and score them, so drift shows before customers notice.

   • Online evaluation
   • Drift
   • Feedback

3. Know the cost

   Tokens, calls and compute per team, per agent and per outcome.

   Explored in Scale: how AI is priced

   • Cost per outcome
   • Budgets
   • FinOps

4. Logs as evidence

   Keep what happened, who approved it and why, for audits and incidents.

   • Audit trail
   • Retention
   • Tamper-evident

1. A switch for every agent

   Pause one agent, one tool or one model at once, without a release.

   • Kill switch
   • Feature flags
   • Pause

2. Limits that hold

   Rate limits, spending caps and timeouts stop runaway loops.

   • Rate limits
   • Budget caps
   • Timeouts

3. Roll back anything

   Prompts, skills, models and policies are versioned, so the last good state is one step away.

   • Versioning
   • Rollback
   • Releases

4. Respond to incidents

   Detect, contain, report and learn, with the same rigour as for any critical system.

   Explored in Govern the agents

   • Incident response
   • Reporting
   • Post-mortem