Nordic APIs 2026 Day 1: Your Next Customer Is an Agent

The theme of Nordic APIs Summit 2026 is Evolving APIs for the Agentic Era. After the UnConference on Monday and the first full summit day on Tuesday, I’d sum up what Stockholm has been saying so far in one sentence: the next caller of your API is not a human, and almost everything we built for humans (keys, consent screens, pre-registration, error messages) breaks when an agent arrives.

I’m at the Clarion Hotel Stockholm all week as an event partner, and tomorrow (Wednesday 14 October, 12:50, Bankettsalen) I’m speaking in the Production Agent Systems track on The API Guardrails Behind Safe Multi-Tenant AI Platforms. These are my notes from the first two days, built from my photos of the slides. Where I quote a number, it is what was on the slide, with the source the speaker gave.

Monday: the UnConference and the Great Sticky Wall

The half-day Nordic APIs UnConference on 12 October had no fixed agenda. Facilitators opened Day 0, attendees wrote topics on sticky notes, and the notes went straight onto a whiteboard.

The result was the Great Sticky Wall: three rooms (C3, C4, C5) and three time blocks, with one discussion in each slot.

What stands out is what people chose to spend a free afternoon on. Of nine topics, at least five were about agents, and the rest were about security or quality. Nobody proposed “how do we design a nicer REST endpoint”. The questions were how do we find agent traffic we didn’t know about, what does OWASP mean when the client is an LLM, and what does “human in the loop” actually mean, and how do we implement it.

My own card asked for four topics I think are missing from most API conversations:

• Agentic commerce: UCP (Universal Commerce Protocol), AP2 (Agent Payments Protocol), A2A together with MCP, and shared payment tokens
• Workload identity: SPIFFE/SPIRE
• Content provenance: C2PA (Coalition for Content Provenance and Authenticity)
• Regulation: Cyber Resilience Act implementations

Commerce turned out to be a theme tomorrow too: the summit has a whole Agentic Commerce track (Zuplo, WEX, Solo.io).

Curity organizes Nordic APIs (it says so on the photo wall), and its OAuth booklets were on the UnConference tables. One spread is worth flagging because it previews the identity discussion on Tuesday. It covers OAuth 2.0 for First-Party Applications (FiPA), Curity’s Hypermedia Authentication API (HAAPI), and browserless OAuth for AI agents:

The booklet gives a checklist for when browserless OAuth is reasonable for an agent: you control the AI agent, you are confident it can handle possibly sensitive user input, and users know it is a first-party agent of your authorization server. For third-party agents the rule is the opposite: the authorization server must ask the user for explicit consent and “must only trust data from AI agents that it can verify”.

The day ended with a reception, and the hallway track started early.

Tuesday morning: three keynotes, one message

Bankettsalen was packed by 9:00. Nordic APIs says there are more than 60 speakers this year, and the room looked like a sold-out conference.

Bill Doerrfeld: How AI agents change API interaction patterns

Bill Doerrfeld, Editor in Chief of Nordic APIs, opened with a reminder of how integration used to work. His slide Finding APIs, circa 2016 listed 12 steps, from “search the internal wiki” and “ask the team: anyone done this?” to “request access from the owning team” and “wait”. The estimate: days to weeks from need to approval, before writing a line of integration code.

Agents compress that to seconds, and the talk walked through the patterns that change as a result: discovery, requests, predictability, capabilities and security. In a live example, a chat assistant answered a question about Stockholm weather from the SMHI open data API. It explained that it “built the URL myself from the known pattern”, and that the result “came mostly from prior knowledge”. That’s the point: agents learn your API on the go, from whatever cues they find.

The numbers that stuck with me:

• 70% of MCP tools don’t tell agents why a tool call failed or what to do next (Arcade.dev’s ToolBench, which graded 92,000+ MCP servers and 640,000+ tools)
• 49.8% of respondents confirmed or suspected that an AI agent took an action their organization did not intend, expect or authorize. Over half of those reported an unauthorized external API call or transaction (Salt Security, State of Agentic AI and API Security 2H 2026, 380+ respondents)

Then came the Silly Mona story: an AI agent given free rein to run a café in Sweden ordered 3,000 rubber gloves for 2 employees and ended up $16,000 over budget. The next slide was titled “Wait, this isn’t silly anymore…”:

Another security slide showed an AI assistant breaking into a gym booking website through an API authorization gap (ABC, August 2026), which was a classic Broken Object-Level Authorization (BOLA) exploit. As the slide title put it, agents will find your authz gaps. His framing: agents act on delegated intent. One intent becomes dozens or hundreds of calls, made under delegated authority at machine speed, and permissions pile up over time into privilege drift. His closing line was simple: Succeed with APIs, succeed with agents.

Jacob Ideskog: Your next customer won’t be human

Jacob Ideskog, CTO of Curity, gave the keynote I’ll be thinking about longest. He started with a village store where a child brings a note from their parent: “No ID. No card. No signature. Just a note.” The shopkeeper trusts it because everyone knows everyone. Agents are that child, but the internet is not a village.

His first point reframed most of the “AI security” talk we hear: internal agents are CISO problems. “We are organizing the back office.” Internal agents aren’t your customers; they’re the staff stocking the shelves. The real shift is external agents arriving as customers. They show up as casual browsers (agents evaluating your API), tourists (sign up once and never return, leaving an abandoned account as a risk you keep carrying) and regulars (your future best customers).

The front door he proposed is Client ID Metadata Documents (CIMD):

1. The client ID is a URL on a domain the caller controls
2. The metadata lives there, with no registration in advance
3. Verify the domain: which family the kid belongs to
4. Assign the client to an organization, automatically

“You don’t have to know the client beforehand. You can verify which domain it belongs to.”

For everything after the entrance, his slide said “None of this has to be invented from scratch”:

• FAPI 2.0: sender-constrained tokens, so a stolen token is worthless
• Token Exchange: so delegation is explicit
• Rich tokens: so the request carries meaningful, trusted data
• Narrow context tokens: so tokens limit access

Banks got here first, with sender-constrained tokens, strong client authentication and no implicit trust, because in open banking every call could be fraud.

Not because they were visionaries. Because they had no choice. The difference is that now none of us do.

His last slide turned security into a selling point: “Agents don’t just get through safely. They prefer to shop there.” The easiest place to get the job done is also the safest place to be trusted with it.

Jeroen Delbarre: Governance in the age of AI agents

Jeroen Delbarre, Director Product Line at Axway, brought the enterprise numbers. Around 62% of organizations are experimenting with AI agents (McKinsey). Fewer than 5% of enterprise apps had agents in 2025, and around 40% are expected to by the end of 2026 (Gartner). 88% of executives plan to increase AI budgets, largely because of agentic AI (PwC).

His three risk buckets had one headline each: data leakage (autonomous agents duped into leaking sensitive data in a phishing test), costs out of control (“The AI agent that cost $47,000 while everyone thought it was working”) and uncontrolled actions (a Cursor agent deleting a production database and its backups through the Railway API). His answer was a governance layer with an agent registry, secure proxies (inbound auth, rate limiting, guardrails, policies), token exchange between agents, budget-based routing to a cheaper model once a budget is exceeded, and orchestration patterns (master/worker, parallel, sequential).

Three keynotes, three speakers and one message: identity, delegation and budget are now API design problems.

Tuesday breakouts: what I sat in on

With three parallel tracks I had to choose. I moved between rooms all day, so here are the sessions where I took notes.

API Green Score (Thierno Diallo, Axa France)

The API Green Score is a framework for assessing the environmental impact of API architecture choices. It defines rules (architecture criteria), gathers evidence (OpenAPI, catalogs, logs, interviews), runs an evaluation (boolean checks or percentage scores) and gives a grade from A to E with an improvement plan. The practical advice applies to agents too: smaller exchanges reduce avoidable work. Filter to the fields you need, paginate, cache valid responses, send deltas only, and track payload size over time.

This connects to Bill’s keynote: every unnecessary field an agent reads costs tokens.

Verifying REST API security with fuzzing (Andrea Arcuri, Kristiania University)

Andrea Arcuri showed how fuzzing can find access-control bugs automatically. A fuzzer can generate a test where user A creates resource X (POST /data returns 201) and reads it (GET /data/42 returns 200). Repeating the last call as user B is trivial. The hard question is: if B gets 200, is it BOLA, or did B have rights to it?

Without a formal access control policy you can’t answer that in general. His approach uses heuristics (and accepts some false positives), takes only an OpenAPI schema and auth info as input, and outputs executable test cases in Java, Python and JavaScript. The tooling is open source. His conclusion: fuzzing finds 500 errors, schema mismatches and HTTP semantics bugs, and it can find “a few BOLA/BFLA even without formal ACP documents”. Agents will probe your authorization gaps anyway, so you’re better off running the fuzzer first.

Agent identity: the missing layer (Jonas Iggbom, Curity)

Jonas Iggbom went deeper on Jacob’s keynote with a vendor checklist I’m going to reuse with clients. Four questions to ask before you ship an agentic system:

1. Is the client_id a URL? Without this, the Client ID Metadata Document spec can’t be used at all.
2. Dynamic metadata fetch, no pre-registration? RFC 7591 Dynamic Client Registration still needs a registry step. True dynamic agent identity means the authorization server fetches the metadata at authentication time.
3. RFC 8693 Token Exchange with the act claim? Without act claim propagation you can’t reconstruct a multi-agent delegation chain in audit logs.
4. Per-agent access policy, not just per-user? “Identity that never reaches the policy engine is attribution, not control.” You need rules like this agent may read documents but never write them, even when its user can do both.

The takeaways: identity is the prerequisite (you cannot audit, rate-limit or revoke an agent you can’t identify). The spec exists and works (draft-ietf-oauth-client-id-metadata-document is live on Bluesky and referenced by MCP). Domain trust needs key binding (pair the spec with private_key_jwt). And your authorization server vendor’s answers to those four questions “tell you everything about their roadmap seriousness”. The closing line: Identity makes the agent knowable. Authorization makes the agent governable.

Open Resource Discovery (Pavel Kornev, SAP)

Pavel Kornev presented Open Resource Discovery (ORD), SAP’s protocol for describing everything an application exposes (APIs, events, data products, entity types, capabilities) in one metadata catalog. The news: MCP servers, AI agents and overlays are now first-class citizens in the ORD spec. A sticker on the slide added that skills, expressed via capabilities so that tools and skills can be described and discovered in ORD, were released in v1.17 the day before.

ORD has been donated to the NeoNephos Foundation, a Linux Foundation Europe initiative that is part of the EU IPCEI-CIS digital sovereignty programme. The trademarks are held by LF Europe and the Technical Steering Committee holds monthly public meetings. This answers the UnConference question about agent traffic discovery from the other direction: if every app publishes what it exposes, shadow MCP servers become much harder to hide.

MCP hands-on: how we opened up APIs for AI agents (Andreas Siegel, pentacor)

This was the most practical MCP talk of the day. Andreas Siegel described four walls every agent hits:

• Discovery: which endpoint, which tool, which capability, which arguments?
• Security: keys in prompts, keys in configs, keys everywhere
• Client: every integration reinvents the wiring
• Governance: who approved this tool call, and who can audit it?

His live “give me your API key” demo showed the anti-pattern: the agent asks for credentials in chat, the user pastes a long-lived token, and the secret now lives in prompt history and logs with no scoping and no revocation path. The second try used one URL, login at the user’s own IdP and a short-lived scoped token. In his words, “no secret ever touches the chat”.

His MCP timeline is a useful reference. 2024-11-05: local tools over stdio. 2025-03-26: going remote, OAuth enters the protocol. 2025-06-18: the MCP server becomes an OAuth resource server (RFC 9728 Protected Resource Metadata) and gets structured tool results. 2025-11-25: richer interactions and CIMD. 2026-07-28: “just an HTTP workload”, stateless and scalable.

The honest slide was No Free Lunch: the effort moves, it doesn’t disappear. Curating tool descriptions is the new integration work. OAuth setup replaces API keys. Someone has to own the gateway, the policies and the audit trail. And the spec changed five times in under two years, so plan for upgrades. MCP solves discovery, security and client wiring. Governance stays your platform’s job.

Agent gateway (Lin Sun, Solo.io)

Lin Sun ran an almost entirely live demo of agentgateway, the open source gateway for LLM, MCP and A2A traffic. She worked through a series of configs: prompt guards, credential injection so the agent never holds the GitHub token, virtual API keys per consumer, routing across several LLM providers, and MCP identity, all checked in the gateway’s playground UI.

This is the architecture I’ll argue for tomorrow: put the guardrails in one control point in front of the models and tools, not in every agent.

Lightning demos: WunderGraph and Gravitee

The demo track had the best number of the day. WunderGraph compared a frontier model exploring a GraphQL schema by itself with their Prompt-to-Capability (P2C) approach on the same question. The frontier model took 33.6 s, 11 turns, 13 tool calls and 58k input tokens, at $0.256. P2C took 4.9 s and 3 model calls with no tool calls, at $0.0048. Letting the agent wander was 6.8x slower and 54x more expensive. The talk title said it: Your AI agent is filling up on bread before the main course.

Dorian Blanc (Gravitee) followed with Building the agent tool layer: from APIs to governed MCPs. His demo put a layer of tools in front of existing APIs (choose, describe and compose them per job), then added controls for data, approval and proof, including a human-in-the-loop approval screen with a decision history. That answers the UnConference HITL question with a working screen.

Closing keynotes

Per the agenda, the day closed in Bankettsalen with a panel on API security in the agentic era (Bill Doerrfeld, Jacob Ideskog, Isabelle Mauny of WSO2, and Curtis J. Schofield of PagerDuty). After that, Jürgen Schulze gave Agents — Viskleken on Steroids, named after the Swedish children’s game where a whispered message gets distorted as it passes along a line. Chain enough agents together and you get the same effect.

What I’m taking into my talk tomorrow

Day 1 left me with five points that I’ll carry into Wednesday:

1. Agent identity comes first. Without a verifiable client identity (CIMD, key binding, act claims) you can’t rate-limit, budget or revoke per agent. Per-user controls aren’t enough.
2. Delegation must be explicit. Token exchange and narrow, sender-constrained tokens are mature, open standards. Banks proved them under pressure.
3. Errors are part of the contract. If 70% of MCP tools don’t tell the agent what to do next, the agent guesses, and guesses cost tokens and create incidents.
4. Cost is a guardrail. The $47,000 runaway agent, the 54x cost gap and budget-based model routing all say the same thing: spend limits belong in the platform, next to authorization.
5. Governance is the platform’s job. MCP doesn’t solve it, and neither does any single protocol. Gateways, registries, policies and audit trails need an owner.

That is exactly the territory of my session: per-tenant quotas, identity propagation, budget enforcement and policy at the API layer of a shared AI platform. If you’re at the Clarion tomorrow, come to Bankettsalen at 12:50, or find me in the hallway.

For the background, see my Nordic APIs Summit 2026 preview, my notes on MCP and AI agent security from conference talks, and my guide to AI agent guardrails in production.