Apidays Amsterdam 2025: MCP, API Security, Terraform

Apidays Amsterdam took place on 6 November 2025 at Tolhuistuin, with the theme “Enterprise GenAI-readiness with the API mindset”. The organiser said from the stage that it was a single day of content and a “human-sized” event after a break since before COVID. The registration page said sold out, and I could see it: the room by the IJ was full from the first keynote. I already wrote one paragraph about it in the Amsterdam autumn 2025 roundup. This is the longer version, based on my photos of the slides and my recordings of the talks.

Two rooms ran in parallel, so I only saw part of the programme. Below are the sessions I recorded, in time order. I name speakers only where the name is on a slide or on the official agenda. When a speaker quotes numbers or makes product claims, I attribute them rather than endorse them.

The main room before the opening keynote.

Opening: a community of API people

The organiser opened by saying the Apidays conferences have run for 13 years, and asked who had been to one before. He asked everyone to introduce themselves to their left and right neighbour, because connecting the people behind the interfaces is the point of the event. He also mentioned three side initiatives: an API industry landscape that maps gateway, documentation and API-ops products, a Women in APIs community, and an online class platform called API Masters. Sponsors thanked from the stage included CAMARA (with KPN), anchr, Axway, Kong and EnableU, plus Akamai, Amsterdam.dev, Solita and API Layer.

Fireside with Ross Mason: AI is not hype, context is the problem

The first keynote was a fireside chat. The agenda lists it as “Fireside Chat with Ross Mason”, Founder of MuleSoft. The host introduced him on stage as the MuleSoft founder, and he described MuleSoft going public in 2017 and being acquired by Salesforce in 2018. He now invests in very early B2B software and infrastructure start-ups.

What I took from the conversation:

• Not hype. He pointed to the visible spending on data centres and chips and compared it with earlier build-outs such as power grids and railways, which were just as large but less visible. His framing was “cognitive power” as a new resource that we do not yet know how to harness, like electricity before the light bulb reached homes. In that picture, standards, protocols and safety measures come after the first inventions.
• Realist, not optimist. He said it would not be pain-free, that jobs will change, and that entry-level work needs a plan, starting with schools and universities.
• A different kind of shift. Cloud, mobile and big data were platform changes; APIs were a packaging and distribution change. In his view, AI is a way of packaging up thinking, and we have no basis yet for doing that.
• Context beats data readiness. The line I noted most was that organisations hold context in humans, not in data. Agents have all the world’s knowledge and no context; people have the opposite. He said that after about three hops an agent starts to “rot” its context unless you check and refresh it, and that the work is building a bridge between human context and data context.
• Where AI works now. Customer support and call centres, because the context is well bounded; coding, mostly for individuals so far rather than for teams; and early sales research and document retrieval.
• For API teams. He suggested spending less time on the contract and more on documentation that LLMs can pick up, and gave an example of an open-source project that grew its monthly downloads after it was discovered through LLM prompts. He did not share how that was measured, so I treat it as an anecdote.

My take: “humans hold the context” is a good explanation for why agent demos work and agent rollouts stall. It also supports the case for keeping API documentation and specs in the repository, next to the code, where an agent can read them.

Axway workshop: the MCP lifecycle behind a gateway

The second room ran a workshop that the agenda lists as “Understanding MCP Lifecycle: A Guided Example with Axway AI Gateway”, presented by Jarno Verrijzer and Jeroen Delbarre of Axway. The title slide in the room read “Full MCP Lifecycle: Workshop using the Axway AI Gateway”.

The workshop title slide, with the IJ behind the stage.

The presenters said the workshop was a recorded demo and walked through its steps on the screen:

1. Set up an MCP server and enforce an API key on it.
2. Add tools to the MCP server.
3. Productise it and publish it to a marketplace.
4. Discover it as a developer or consumer on the marketplace.
5. Configure a desktop AI client from the marketplace documentation and use the server there.
6. Look at the business insight (analytics) at the end.

In the demo the server was called “file repository” and front-ended an Amazon S3 bucket. The access governance rule expected an API key in the query string; they said OAuth is supported too but used a key for the example. A slide titled “AI Gateway” grouped the building blocks: MCP, Agents, LLM connectors, an LLM orchestrator, token management, guard rails, prompt templates, a prompt decorator, access control and data management, sitting between AI and non-AI applications. MCP and access control were highlighted.

The “AI Gateway” slide, with MCP and access control highlighted.

The point of the demo was that an MCP server is managed like any other API product: it has a key, a marketplace entry, documentation and usage analytics. For the vendor’s own description of the product, see the Axway Amplify AI Gateway page. The protocol itself is described on the MCP site, and its authorization section is where the OAuth side lives. I compared client support in MCP adoption by client in 2026.

My take: this is what I expect most enterprises to do first, which is to reuse the gateway they already operate for rate limits, keys and audit, and put MCP servers behind it. The open question is how fine-grained the tool-level governance can get, because an API key on the server says nothing about which tool an agent may call.

API security: from exposure to resilience

After lunch, the host introduced a talk by Akansha Shukla of ABN AMRO NL. The agenda title is “API Security: From Exposure to Resilience”; her slide read “API SECURITY: Turning Complexity into Confidence”, subtitled “A Strategic Framework for Modern Resilience”.

The API security title slide.

She started by asking how many people in the room were security professionals and how many were developers; there were more developers. Her argument was that the gap between the two groups is where API security fails, and that the answer is a control framework, not just another tool. Key points as I heard them:

• API sprawl. The number of APIs grows faster than inventory and documentation, and business logic flaws are exploited, not just bugs. She cited the 2022 Optus breach as an example of broken object level authorization (BOLA), which still tops the OWASP API Security Top 10 as API1:2023.
• The gateway illusion. A gateway validates tokens, rate-limits and routes, but it does not understand payloads. A legitimate, authenticated user can still call endpoints they should not, so a gateway is not 100% security.
• AI and API are one topic. She disagreed with treating AI security as a separate domain: prompt injection and BOLA are related problems, and AI agents talk to APIs.
• Four layers, three pillars. She grouped the Top 10 into business and application, data, identity and access, and network and service layers. The three pillars were design and development (start with threat modelling, schemas, static and dynamic testing, dependency checks), policy enforcement at the edge, and runtime and data protection with monitoring. She gave an illustrative split of roughly 70/25/5 across the three phases and called her figures hypothetical.
• Measure it. Track API discovery coverage, mean time to detect and recover, and the number of high and critical findings, and feed the results back to design, like a CI/CD loop. She also mentioned DORA, GDPR and PCI DSS as drivers.

My take: the “gateway illusion” slide is the one to show a platform team that thinks a gateway closes the security question. Object-level authorization has to live in the service that owns the data.

Event streaming at a postal operator

I also recorded a talk that the agenda lists as “Consumer and customer integrations using event streaming in a postal operator”, by Kristi Du Toit of PostNL. She described moving parcel track-and-trace updates from batched files, delivered to big customers every 20 minutes, to events processed as they happen. As she put it, a parcel moving through the network triggers events, event processors sit in the middle as a buffer, and the producers (back-end teams) and the consumers (customers and consumer notifications) are decoupled from each other. According to her, the target is real-time delivery within about eight seconds, with prioritised events such as “driver is on route”, and processors that scale up for Black Friday and Sinterklaas.

She was candid about the downsides: stakeholders have to leave their comfort zones, new dependencies keep showing up, and there are ownership and governance questions about the data. Customer files were still being batched in the transition, which she joked was like “a horse-drawn carriage selling a Lamborghini”. Her message to smaller customers was a gradual move from polling APIs to a “don’t call us, we’ll call you” pattern. Parcel notifications to consumers were the first complete chain running through the event processors.

Twilio: Number Verify and telco APIs

Cedric Villerio of Twilio (his slide says Carrier Relations) presented “Improve user verification experiences & conversion with Number Verify (SNA)”, in the fraud track that the agenda calls “Mobilizing against fraud”. The framing was the CAMARA telco APIs, a project the conference had as a gold sponsor.

The title slide of the Number Verify talk.

According to the speaker, silent network authentication verifies the user’s phone number through the mobile network, without an SMS code, so the user stays in the app. He compared it with hardware tokens, mobile apps and SMS one-time passwords, and listed use cases: banks, insurers protecting beneficiary changes, ride-hailing onboarding, loyalty-programme abuse and government digital identity. The numbers he gave (conversion gains, seconds saved per login, customer examples) are Twilio’s own, so I will not repeat them here; Twilio’s documentation covers Silent Network Auth. His practical lessons were useful regardless of vendor: coverage is not 100% and it does not yet work over Wi-Fi, so you need a fallback such as SMS; it takes longer to deploy than SMS; and it touches fraud, support and marketing teams, so you need a compelling event to get it prioritised.

API security and the “theme park” view

Later in the afternoon, I recorded Jimmy de Leeuw of EnableU (agenda: “API Security in the everchanging world of AI”). He built the talk around theme-park metaphors: queues and checkpoints, the one lane into the main stage, and a “future ride” balanced between AI and human control. Points I noted:

• Attacks often arrive through a weaker partner, so multi-hop attacks are the pattern to watch, and most organisations have little detection on their APIs. He cited industry statistics for this; I did not verify them, so treat them as his.
• AI agents now impersonate humans with ordinary API keys. Authentication is easy, authorisation is harder, and identification of “is this an agent?” is the hardest part.
• AI helps with real-time anomaly detection, so one person can watch the dashboards that used to need five.
• An old technique is back: strict schema validation at the edge, rejecting anything that does not match. His team applies it for Dutch municipalities.
• Digital identity and wallet regulation in the EU was the context for his remarks on FIDO and authentication standards.

Terraform for AWS serverless

The last session I recorded was “Unlocking AWS Serverless with Terraform” by Andre Lopes of Tesla, which his title slide confirms.

The last talk I recorded, in the room by the park.

He started with definitions. Serverless means handing the management of the infrastructure to the cloud provider; he called it “service as a service”. On AWS he counted API Gateway, Lambda, SQS and S3 as serverless because you do not provision machines for them. He contrasted a classic server, which must scale and bootstrap before it can take traffic, with an API Gateway in front of Lambda, where each request is handled on its own and you pay only while it runs. He mentioned 1,000 concurrent Lambda executions; that is the default per-Region quota in the Lambda documentation, and it can be raised. He also warned that serverless hype led some teams to convert everything and then get a high bill at the end of the month, so he recommended choosing what really needs to be serverless.

The Terraform half explained infrastructure as code as writing blueprints of the desired state, not scripting steps. His arguments:

• Reuse. Locals and variables for tags and environments, and modules so fifty Lambdas do not mean fifty hand-written blocks.
• Consistency. The same code in two accounts or regions removes errors such as a missing IAM policy that only shows up in production.
• Review and standards. The infrastructure lives in a repository you can search, and CI/CD can scan the code to block policy violations before deployment.
• Versioning. Rolling back a bad change is reverting a commit.
• Portability. One language across clouds. He said AWS CDK is excellent but ties you to AWS; in Q&A, someone asked him to compare it with Terraform.

The live demo built a small REST API: an API Gateway with a GET method, a DynamoDB table with seed data, a Lambda with initial placeholder code (a function cannot be created without code), and its IAM policies. He used a remote S3 backend for the state, since CI/CD runners never get the same machine twice. The GitHub Actions workflow ran init, fmt, validate, plan and apply, with destroy to reset everything. He deployed the function code separately with the AWS CLI, because he prefers to keep it apart from the infrastructure code. The first run failed because the Lambda was not there yet, and a missing GetItem permission on the policy had to be fixed live, which was a fair demonstration of his point about plan-before-apply.

If this is your area, I wrote more on Terraform state management and Terraform module best practices.

Closing

In the closing words the organiser called the day a test that worked: the community came, the event sold out, and, as he put it, the right people were in the room, dealing with data management, AI gateways and “MCP all the way down”, and explaining to the business why governance takes time. He thanked the speakers, sponsors and staff.

My overall take: the main threads were the same in every room. Agents are API consumers, so existing API discipline (keys, gateways, schemas, documentation, inventory) applies directly, and the gaps are authorisation granularity and context. The unglamorous speaker advice was the most useful, such as threat-model first, keep a fallback, and plan before you apply.

Related

• Amsterdam AI and Dev Meetups, Autumn 2025: A Roundup
• MCP adoption by client in 2026
• Terraform state management guide
• Terraform module best practices