The Cloud Native AI Summit is landing in Melbourne (Oct.28-29) and Paris (Dec.2-3) and we are excited to announce that our Call For Papers open and is running until August 14th!

As a technical independent conférence, we will ask one big question: how do we build the Cloud Native foundations to power the AI Era?

Our editorial Manifesto will be serve as a readmap.

We’ll follow a strong focus on large-scale corporations, multinational organizations and industry leaders to address technical depth,  share cutting-edge innovations and real use cases.

Our Editorial Manifesto has been crafted for Practitioners and scope the whole discussion.

To ensure every session meets the highest technical standards, our agenda is strictly vendor-neutral and carefully curated by Chris Mazur, AAIF & CNCF Ambassador and original founder of the Cloud Native Summit, and Mehdi Medjaoui, Apidays CEO.

To explore this, we are looking for talks across our three core tracks:

Our audience is made of Platform or Infrastructure Engineer, DevOps/SRE, Network or Software Architect, AI & Application Developer, Security Professional, mostly senior working in large-scale organizations.

So, if you are working on the convergence of cloud-native foundations and the AI imperative, we want you on board!

Critical dates to keep in mind:

Looking forward to hearing from you!

Community Spotlight

Corey Ball is the founder and CEO of hAPI Labs, a consulting firm focused on API penetration testing, and the founder of APIsec University, a free platform that has trained more than 100,000 students in API security. He is best known as the author of Hacking APIs, a hands-on guide to breaking and defending web APIs. His work sits on the offensive side of the field: finding the flaws in an API before someone else does.

His argument is that APIs are now where sensitive data and business logic reside, making them a direct route into an organization's systems. Standard web application testing does not fully cover them. API-specific flaws such as broken object-level authorization, broken authentication, excessive data exposure, and missing rate limits need their own tools, methods, and mindset.

Much of Ball's contribution is turning that mindset into something teams can actually learn. Through Hacking APIs and the APIsec University courses, he walks practitioners through a repeatable process such as mapping an API's endpoints, analyzing how authentication and authorization behave, fuzzing inputs, and chaining smaller weaknesses into larger exploits, all against intentionally vulnerable practice targets. The emphasis is on practice over theory.

He is also an active contributor to the OWASP API Security Top 10, the reference most teams use to categorize API risk. A recurring argument in his work is that security testing should move earlier in the development cycle rather than as an annual audit, because APIs change too often for once-a-year testing to keep pace. For teams that ship frequently, that means treating security tests like functional tests and making them part of every release.

That shift also changes who owns API security. As testing moves into the build process, it is no longer solely the security team's responsibility. Engineers and developers need to understand how their own APIs can be attacked, which is part of why Ball built a free, open curriculum. The aim is to make adversarial testing a routine engineering skill.

As more traffic comes from automated agents and AI systems, the attack areas continue to grow, and the same authentication and authorization flaws become easier to exploit at scale. Ball's advice for API teams is to know your full API footprint, test it as an attacker would, and do so continuously.

API Feed

Big Story

For much of the modern web, API authentication was treated as a relatively straightforward engineering decision. Internal systems commonly relied on API keys, consumer applications adopted OAuth, and highly regulated environments implemented mutual TLS where stronger assurances were required. Once selected, the authentication model often remained unchanged for years because the types of API consumers changed very little. Most requests came from applications, mobile clients, or trusted integrations operating within predictable environments.

Enterprise API ecosystems no longer look like that.

Today's APIs serve a diverse set of consumers. Cloud-native services communicate continuously across distributed environments. CI/CD pipelines provision infrastructure automatically. Third-party platforms integrate through partner APIs. Most recently, AI agents have emerged as autonomous API consumers capable of discovering, invoking, and chaining together multiple services without direct human intervention. These consumers do not carry the same level of trust. Authentication now has to show what is making the request, who it represents, what conditions apply, and how long that access should last.

According to CyberArk, organizations manage approximately 82 machine identities for every human identity, with more than 40% of those machine identities holding privileged access. At the same time, industry security research continues to show that long-lived credentials remain one of the most common causes of credential exposure and privilege misuse across cloud environments. Every new workload, service, and automated process introduces another identity that must be issued, managed, monitored, and eventually retired.

Standards are moving in the same direction. OAuth 2.1 brings earlier implementation guidance into the core specification by requiring Proof Key for Code Exchange in authorization code flows and removing older patterns such as implicit grant. In financial services, FAPI 2.0 strengthens token protection through sender-constrained access tokens, using methods such as Demonstration of Proof of Possession and mutual TLS, so that an intercepted token cannot be reused without the matching cryptographic credential. The larger shift is away from permanent shared secrets and toward short-lived credentials tied to context, scope, and the system that uses them.

Perhaps the most significant evolution is the rise of workload identity. Instead of distributing API keys or storing service account credentials, platforms such as SPIFFE/SPIRE, Google Cloud Workload Identity Federation, Microsoft Entra Workload ID, AWS IAM Roles, and Anthropic's recently introduced Workload Identity Federation authenticate workloads based on cryptographically verifiable identity issued by the execution environment itself. Developers no longer manage secrets directly. The infrastructure establishes trust dynamically using short-lived credentials tied to verified workloads. This approach not only reduces the operational burden of secret rotation but also aligns authentication with Zero Trust principles that assume no workload should be trusted implicitly.

The emergence of AI agents reinforces this direction. The Model Context Protocol (MCP), which is rapidly becoming a common standard for connecting AI agents with enterprise systems, builds upon OAuth, allowing organizations to extend existing identity and authorization practices into agent-driven environments. Rather than creating another authentication model, the industry is converging around stronger implementations of established standards.

None of this suggests that API keys are becoming obsolete. They remain appropriate for narrowly scoped internal services, prototypes, and lower-risk integrations where operational simplicity outweighs the need for sophisticated identity management. OAuth continues to provide the preferred model for delegated user access, while mutual TLS and workload identity strengthen trust between services and infrastructure. The question is no longer which authentication mechanism is universally best. Each solves a different trust problem, and mature API platforms rely on multiple mechanisms working together.

The practical lesson is that API authentication can no longer be chosen once and left alone. API consumers now include users, services, cloud workloads, partners, and agents, each with different authority and different risk. API keys may still fit narrow internal use cases, but higher-trust environments require stronger proof of identity, tighter scope, shorter lifetimes, and protection against token reuse. The right mechanism is the one that matches the caller, the action, and the consequence if access is misused.

Resources & Events

apidays India brings together API architects, platform engineers, developers, and enterprise technology leaders for two days focused on the next generation of API-driven systems. The 2026 program explores how APIs are evolving to support AI agents, autonomous workflows, and machine-driven ecosystems, alongside sessions on API monetization, security, governance, platform strategy, and AI-driven automation. Designed for teams building and operating modern digital platforms, the event combines technical deep dives, practitioner-led case studies, and real-world discussions on how APIs are being designed, secured, and managed in an AI-connected world. Details →

apidays Toronto brings together API architects, platform engineers, developers, and enterprise technology leaders for two days focused on building APIs for AI agents. The 2026 program, themed around the execution layer for the agentic era, covers API monetization, security, AI-driven automation, governance, and emerging technology trends across 100+ sessions. Speakers include senior leaders from Salesforce, Walmart, and Asana. Details →

You can find a list of all Apidays events here

Apply to speak at Apidays Singapore, NY, London, Paris, and more here

The Gartner Identity & Access Management Summit brings together IAM leaders, security architects, platform engineers, and enterprise technology executives for three days focused on modern identity strategies in an AI-driven enterprise landscape. The 2026 program explores identity governance, identity threat detection and response (ITDR), Zero Trust, non-human identities, workforce and customer IAM, cybersecurity, and secure automation, alongside discussions on managing machine identities and AI-powered systems at scale. Details →

Gravitee's State of AI Agent Security 2026 report highlights a widening gap between enterprise AI adoption and security governance. Surveying more than 900 executives and technical practitioners, the report found that 88% of organizations experienced a confirmed or suspected AI agent security incident during the past year, while 82% of executives still believed their existing policies were sufficient. Perhaps most notably, only 21.9% of organizations treat AI agents as independent identities, with 45.6% continuing to rely on shared API keys for agent-to-agent authentication. Read →

Insight of the Week

MCP tool poisoning targets the trust layer between an agent and the tools it can call. A tool can keep the same visible name and user-facing summary, while its hidden description is updated to prompt the agent to collect the last 30 unpaid invoices and attach them to a routine call. Because the request uses the analyst’s permissions and targets an approved MCP server, it can appear to be normal workflow traffic. The impact is that a small server-side change can turn an approved integration into a path to a data leak. Enterprise agents are projected to grow from 28.6 million in 2025 to more than 2.2 billion by 2030.

For the Commute

In this session, Gbadebo Bello explores what it actually means to make APIs agent-ready, arguing that model intelligence alone cannot compensate for poorly designed interfaces. He shows how machine-readable OpenAPI specifications, well-defined JSON Schemas, richer error semantics, and standardized protocols such as MCP enable agents to understand, invoke, and recover from API interactions more efficiently. He also discusses discoverability, secure authorization, and why APIs should expose structured context.

Stay tuned for bold ideas, fresh perspectives, and the next wave of API innovation

-The Apidays Team