The question is how that response gets requested. 

The agent ran. It checked the queue, detected the anomaly, made the call. Then it produced a tidy summary (decision, rationale, confidence score) and delivered it to the person who was watching. 

That’s the happy path. The fact of the matter is that most runs aren’t that clean.  

One failure, a dozen scenarios

Each of the cases listed below is a version of the same failure: the agent did its job, but the result didn’t reach the right person:

• The agent hit a step it couldn’t resolve and stopped, waiting for an approval that nobody saw.  
• A decision came back ambiguous and needed a human call, but there was no way to surface that to the right person in time.  
• An edge case surfaced mid-run that the original prompt didn’t account for, and the agent had no way to escalate it. By the time anyone noticed, the context was stale. 
• The colleague who needs to act on the decision wasn’t in the thread. The on-call engineer isn’t watching the terminal.  
• The automated pipeline that ran at 3am had no audience.  

The agent’s output is readable, but it’s trapped in the interface that produced it: visible to whoever happened to be present, invisible to everyone else. 

Connecting the agent to a messaging channel doesn’t solve the problem entirely, but it does extend the reach of its output beyond the interface it ran in.  

Tool count is an architectural decision 

The practical question is how to do it properly. Most messaging MCP servers are built for full-featured channel integrations: scheduling, logs, template management, bulk sending. That’s useful if you need it. But for an agent that just needs to notify someone or request a human decision, you’re loading a lot of tools into the model’s context that have nothing to do with the task. 

Every tool you expose to an LLM costs more than the API rate card suggests. The tool’s schema, name, description, parameters, gets injected into the model’s context on every invocation. A server with 27 tools loads 27 definitions into every request. The model them has to reason over all of them. 

That’s not always a problem. If your agent needs scheduling, delivery logs, carrier-level capability checks, or template management, a full-featured channel server earns its footprint, and it’s typically the most common go-to use case for messaging MCP servers. 

But if the agent just needs to notify someone, you’re paying a context tax on 26 tools you didn’t ask for. 

This is the argument behind deliberately minimal MCP servers: for simple use cases, smaller is also more accurate, not just cheaper.  

What “minimal” could look like in practice 

When Infobip talked to developers using its MCP ecosystem, a pattern emerged: some of them weren’t reaching for the full feature set. They had a pipeline, an agent, and a need to notify someone (sometimes to attach a screenshot while at it).

The Infobip Message MCP server is a direct response to that feedback: one or two tools covering SMS, RCS, and Viber, with support for images where the channel allows for it.  

There’s something worth noting in that design choice. The broader Infobip MCP ecosystem includes channel-specific servers with rich feature sets: the RCS server has 27 tools, WhatsApp has 18. The Message server sits deliberately at the opposite end and caters to use cases that only require low footprint.  

It’s not a replacement for the channel-specific servers, but a different tool for a different job. The agent can then send a notification across three different channels from a single tool call. 

The pattern behind the product 

Out of this integration comes an interesting trade-off to consider: how does the minimal-footprint pattern hold up as agents get more capable? 

Agents take on more complex workflows. The instinct is to give them more tools, more context, more capability, and more surface area. But since the relationship between tool count and agent performance is not linear, past a certain point, more tools will always mean more ambiguity about what to call, more opportunity for hallucinated parameters, more tokens spent on reasoning over options rather than executing. 

For narrow, high-frequency actions (notifications and alerts being the clearest example), there’s a real case for purpose-built tools that do one thing and declare that scope clearly. Not every agent capability needs the full API surface. 

Whether that principle scales to more complex tasks, and whether the industry converges on a layered tool architecture rather than a flat one, is still an open question.  

But for now, for the specific problem of “my agent needs to reach a human,” starting minimal and adding surface area only when the use case demands it seems like a more defensible approach.   

The post Human Decisions Are The Real Bottleneck Of Agent Design appeared first on ShiftMag.

What began as an internal hackathon project, where a small team at Infobip set out to create and launch a marketing campaign for a fictional chocolate brand using AI agents, evolved into the company’s first MCP servers running in production.

At Devoxx UK, Filip Srnec, Principal Engineer at Infobip and lead of the company’s MCP team, explained how they built the OpenAPI MCP Spring Boot Starter, a tool that turns any OpenAPI-documented API into a fully capable MCP server, without the need for rewrites or custom integration code.

Why not just build custom MCP servers?

Filip kicked off his talk by asking the audience if anyone had an HDMI adapter so he could point out a common challenge in technology:

Protocols evolve, and systems don’t necessarily upgrade in sync.

Most of the systems AI agents need to interact with today already expose REST APIs. REST APIs helped us build the world that we now today. Mobile apps, smart devices, command-line tools, and interactive user interfaces all rely on them, running on top of decades of standards, tooling, and shared knowledge. Now AI agents need a way to use that same infrastructure.

MCP, announced by Anthropic in November 2024, was positioned as “a USB-C port for AI applications.” That immediately raised the question of whether every existing API (the HDMI cable) would now need custom glue code (an adapter) to become agent-accessible.

Infobip’s answer was no.

The OpenAPI connection

The breakthrough came when the team compared the structure of an MCP tool with an OpenAPI operation. The two map directly onto each other at the field level. MCP tools define elements such as a name, title, description, input schema, and annotations, while OpenAPI operations include an operation ID, summary, description, parameters, and request body. Comparing the two side by side shows that most OpenAPI operation metadata already has a direct equivalent in MCP:

The name can be an operation ID, because operation ID uniquely identifies an operation in the specification. For a title, we can use a summary. Description is obvious. We have a way to define the input schema by combining parameters and the request body.

Infobip already had OpenAPI specifications for all of its public APIs. Since those specifications were powering the company’s API platform and SDK generation process, building a bridge to MCP made more sense than creating custom servers from scratch.

Let’s take a look at how the OpenAPI MCP Spring Boot Starter works in two phases.

How the framework works

The process begins by reading the OpenAPI specification and turning it into MCP-compatible tool definitions. Because the connection is dynamic, updates to the API are reflected on the MCP side as well.

At runtime, on every tool call, the framework validates credentials, maps tool arguments to HTTP requests, enriches and forwards those requests to the downstream API, handles errors, and returns the result to the agent.

The setup is intentionally minimalistic. It requires only the OpenAPI specification URL and the base URL of the API being exposed. As Filip explained:

You just point it at your OpenAPI specification, and your API instantly becomes an MCP server. This is something that we’ve been running in production for months now.

Not every endpoint should become a tool

Filip pointed out that exposing an entire API surface to agents is a bad idea. Irrelevant operations add noise, increase costs, and can mislead the model. A larger surface also extends the potential attack surface for prompt injection.

The framework tackles this through an OpenAPI filter chain. Before tools are exposed through MCP, developers can adjust the specification. That means removing endpoints, tweaking schemas, or changing how operations are presented. The good thing is that this approach works even when the API is maintained by someone else.

One example involved OpenAPI’s discriminator feature. It is commonly used to select different schemas based on a property value, making server-side validation more flexible. The catch is that discriminators are not valid JSON Schema constructs, while MCP tool definitions require strict JSON Schema compliance. To solve the problem, the framework automatically rewrites discriminator-based schemas into oneOf structures that MCP clients can consume without issue, Filip explained.

Unfortunately, exposing the right tools solves a part of the problem. For an AI agent to use a tool correctly it needs to understand both what the tool does and when to use it.

Naming, descriptions, and making agents actually use your tools

LLMs select tools based on names and descriptions and both matter more than most developers realize.

The framework gives developers several ways to name tools. They can keep the original operation ID, use a simplified version with special characters removed, or generate a name from the API endpoint itself when no operation ID is available. It also includes safeguards for clients that impose strict limits on name length.

Tool descriptions require just as much attention because every description from every connected MCP server is loaded into the model’s context. These descriptions need to be concise and easy for AI agents to interpret. The framework can enrich them with summaries and examples from the OpenAPI specification, which Filip highlighted as especially useful when matching requests to input schemas.

The tools, however, still need to work with existing authentication and authorization systems.

Solving authentication without reinventing it

Authentication has been one of the more debated aspects of MCP and because of that the framework takes a pragmatic approach by relying on existing mechanisms rather than new ones. Filip explained:

Your API already knows how to perform authentication and authorization. It knows how to reject bad credentials.

Instead of introducing a separate authentication layer, the framework forwards credentials to a configurable endpoint that already handles it. As a result, any method supported by the underlying API, whether API keys, basic authentication, or JWTs, works through the MCP server as well.

For OAuth, the framework proxies OpenID configuration calls and authorization requests to a configured OAuth server, and performs automatic scope discovery from the OpenAPI security definitions:

To have full OAuth support, you need to point it at your OAuth server. And you’ll get minimal scope discovery automatically directly from the framework.

It is important to mention that building the features was, once again, only part of the story. The team was also developing the framework while the MCP ecosystem itself was still taking shape.

Building on a moving train

Filip was candid about the challenges the team faced. As Infobip was building and shipping the framework, the MCP specification evolved, with changes affecting everything from transport mechanisms and authentication flows to client behavior:

Sometimes we need to pick between features and compatibility. We decided that we wanted to move fast. We wanted to be in that space. The spec was still being written while we were shipping production code.

Along the way, the team had to deal with a growing list of compatibility issues. Different clients imposed different limits on tool name lengths, some sent nested objects as escaped strings instead of valid JSON, and OAuth implementations often behaved differently despite following the same specification:

My point here is that sometimes you can’t wait for the ecosystem to mature. You ship and you adapt.

The demo

Filip wrapped up the session with a demonstration. Using the framework, he connected an OpenMeteo weather forecast server and Infobip’s production SMS MCP server, then showed how an AI agent could retrieve the next day’s weather forecast for London, generate a short summary, and send it as a text message. The point was how quickly an existing API could be turned into an MCP-compatible service. As Filip put it:

Your API may already be a hidden MCP server. Try to use this framework, point it at your specification, and ship it.

• Listen to Filip’s entire talk on YouTube
• The framework and examples are open source and available on GitHub.
• Infobip’s production MCP server is accessible at mcp.infobip.com.

The post Your API Is Already a Hidden MCP Server, You Just Need to Discover It appeared first on ShiftMag.

This shift feels both fascinating and unsettling. Because of that, the need for clear rules and a neutral authority has never been greater. Such a framework must ensure balance so that AI develops in a way that remains fair, transparent, and aligned with human needs.

That need led to the creation of the Agentic AI Foundation (AAIF) within the Linux Foundation in December last year.

AAIF builds open, neutral foundations for agentic AI through collaboration – not control

AAIF mission focuses on neutral governance, open standards, and a collaborative ecosystem. The goal is to prevent a small number of proprietary companies and platforms from dominating AI.

In this context, the Linux Foundation provides reliable infrastructure, much like Linux does for operating systems or Kubernetes does for cloud environments. It ensures that these technologies remain open, secure, and interoperable.

Agentic AI Foundation hosts the Model Context Protocol (MCP), the emerging open standard that defines how AI agents communicate with external platforms, tools, and services. Companies that collaborate within AAIF will help determine which platforms will shape the infrastructure of the agentic AI era. Mazin Gilbert, Executive Director of the Agentic AI Foundation, stated:

The Agentic AI Foundation (AAIF) is the connective tissue, the plumbing behind how agentic systems operate. No one company can define or own these standards. We’ve seen this in cloud native with CNCF and in networking with the LFN. At every inflection point, the world moves from experimentation to production, and that shift needs open standards and community collaboration. With 170+ companies already in AAIF, we’re clearly at that inflection point in Agentic AI today.

What changes in the infrastructure when moving from APIs to AI agent-based systems

To better understand AAIF’s mission firsthand, I interviewed my colleagues, two developers from Infobip, a gold member of the foundation and the publisher of Shiftmag!

Josip Antoliš and Filip Srnec described how agentic AI transformation looks from a developer’s perspective, what changes it brings, which challenges arise, and what AAIF membership enables when it comes to participating in a global AI community.

We began by discussing what changes at the infrastructure level when moving from traditional APIs to AI agent-based systems. Josip Antoliš explained that MCP lets developers assign tasks to AI agents and ensures agents execute them in a standardized way. In practice, service providers who built products through HTTP APIs should now consider exposing the same functionalities through MCP.

In some cases, APIs can adapt automatically into MCP servers.

As an example, he noted that Infobip has open-sourced its own framework for exposing any HTTP API as MCP. He described this as only the first step. He explained that protocols like MCP let different agent systems connect, allowing one AI agent to delegate subtasks to another in a different environment through an MCP call. This makes it easier to build independent agents that collaborate, turning API providers into agent providers.

He also noted that AI agents become more valuable with every new tool they connect to, creating a positive feedback loop similar to network effects:

For example, an AI agent connected to an MCP server that tracks the stock market can analyze trends and suggest actions. If connected to a messaging provider like Infobip, it can send proactive SMS alerts when opportunities appear. Adding a trading tool then allows users to reply and instruct the agent to execute trades. Each new tool increases the value of all previous tools.

API providers are becoming agent providers

Filip Srnec expanded on this perspective by pointing out that Infobip’s mission to reach users wherever they are, through any available channel, naturally aligns with the agentic world. Their communication capabilities allow agents to interact through channels that users already know:

As we like to say, by using Infobip, AI agents gain communication superpowers. This applies across industries: agents that manage flight bookings and reminders, agents that run e-commerce processes, or marketing agents that create meaningful campaigns targeted at the right user segments.

He highlighted that Infobip has developed a range of products in the agent space, such as AgentOS, along with tools for connecting agents, including MCP servers. These solutions bridge the gap and enable agent-driven communication experiences:

From setting up communication through channel activation, sending messages, and feeding responses back to agents, Infobip covers the entire process. In addition, our platform offers advanced message optimization, fraud detection, and communication flow design.

Challenges in adopting MCP

Early-stage ecosystems often lack structure, and MCP is no exception. I asked my interviewees to identify the biggest gaps and limitations they encounter when building production-ready agent systems. Filip acknowledged that the ecosystem still feels unstructured, especially when it comes to adopting new standards and terminology:

I work in the MCP value stream, and we experience this firsthand. The biggest issue is that third-party client software, such as MCP clients, varies in maturity. Because of that, we cannot assume that everything behaves exactly according to the specification.

He added that specifications and terminology evolve quickly in this emerging space. These changes sometimes introduce breaking issues, both intentional and unintentional. Teams must remain agile and constantly balance product delivery with compatibility.

Josip pointed to another challenge. Anthropic originally developed MCP with a focus on coding use cases, particularly for its Claude Code assistant. Some assumptions from that use case remain embedded in the protocol:

For example, one of the two available deployment options requires the MCP server to run on the same machine as the AI agent. That works for servers that manipulate or compile local source files, but it becomes impractical when exposing functionality over the internet.

MCP does support remote servers, which enables broader use cases. Even so, authentication and authorization still require significant effort:

MCP adopted the OAuth specification. While this supports adoption, MCP relies on relatively niche parts of OAuth, which makes full compatibility harder to achieve.

How AAIF helps address these challenges

Since governance of the MCP specification moved to the AAIF, development and priorities have become more open and better aligned with the broader ecosystem, as Josip observed. The 2026 roadmap highlights key improvements such as scalable remote deployment, support for long-running tasks, and stronger enterprise readiness, including observability and integration with existing authentication systems.

These changes should make MCP servers easier to maintain and open the door to more complex use cases and new markets. Josip drew attention to the choice of Streamable HTTP as a transport protocol, which remains somewhat controversial:

Although it limits horizontal scaling, keeping it at this stage helps prevent fragmentation of the ecosystem. Planned improvements in this area will be especially important for DevOps and production environments.

He underlined the importance of support for long-running tasks. These tasks allow agents to manage processes that run for hours, opening entirely new categories of use cases. Improvements in enterprise integrations, especially single sign-on, will prove critical for broader adoption, since current complexity creates real barriers in production environments.

What does it mean to be AAIF member?

When discussing Infobip’s role as a Golden Member of the Agentic AI Foundation, I wanted to understand how this membership influences internal technical decision-making compared to simply adopting external standards.

Josip noted that the AI ecosystem evolves rapidly, and new standards seem to appear constantly. However, standards only create value when people adopt them. By participating in AAIF working groups, his team gains insight into the direction of key industry players:

We contribute by sharing our use cases and drawing attention to the challenges we encounter in our own implementations.

This involvement allows them to align new features and even entire products with the direction in which technology is moving:

Choosing the wrong technological direction can become expensive and create significant technical debt. By participating in AAIF activities, we ensure that we move in the right direction instead of following ideas that lead nowhere.

Through AAIF Josip stressed the importance of bringing real-world use cases into technical discussions from the very beginning. Standards that fail to address real user needs rarely succeed. Early input helps embed key concepts from the start instead of adding them later.

Filip described AAIF membership as a source of confidence and stability in the emerging agentic AI landscape. Open standards like MCP ensure that development does not rely solely on commercial interests. The community develops, maintains, and governs the technology together:

From the perspective of a developer building agent-based applications today, open standards provide strong foundations, best practices, and proven design patterns. This ensures that solutions remain robust and independent of any single vendor.

He pointed out that MCP acts as a universal connector for external tools and data sources. Building on open technologies allows individual engineers to become part of a global community and even influence the future direction of technology.

Filip concluded by noting that global collaboration remains essential at this stage, especially when it comes to reliability and security. The era of agentic AI has already begun. Many agents already operate in production. Now is the time to build a stable ecosystem that allows everyone to develop and use this technology safely.

The post How Agentic AI Foundation and MCP Are Redefining the Infrastructure for AI Agents appeared first on ShiftMag.

Roland Liposinović, Security Governance Generalist at Infobip, sees a critical shift: security should no longer be an afterthought or a compliance checkbox:

Make security a growth tool, not a tax. Build safety in from day one, and audits finish faster, big customers say yes sooner, and purchasing roadblocks disappear.

This mindset shift is one many organizations still struggle to make.

Too often, security is treated as a necessary evil, something to appease auditors and regulators. But Roland argues that security-first development is a competitive differentiator. By integrating controls early, companies can unlock new markets more quickly, shorten sales cycles, and establish trust in ways that directly impact the bottom line.

Security isn’t red tape. It’s quality control for modern, AI-powered products. Trust drives sales. Secure design grows trust over time.

Embed security across the entire development lifecycle

The question, then, is how to embed these practices across the entire software development lifecycle, from planning and coding to testing, deployment, and operations, without slowing down AI-driven innovation.

Roland’s answer is to make security invisible, automated, and developer-friendly.

“Think automatic seatbelts, not checklists,” he says. At Infobip, the team embeds rules directly into their cloud setup and delivery pipelines, ensuring that “the safe way happens by default.” Automated checks scan for vulnerabilities, exposed secrets, risky dependencies, and unvetted model files every time developers save code. If something is off, the build fails fast with clear feedback.

Feedback should arrive in minutes while developers are still working, not days later. Security runs next to the team, not in front of it, blocking the door.

One additional thing you can do before major projects is run lightweight risk assessments focused on a few key questions: How could this feature be misused or abused? What data does it touch? Who could misuse it? This practice, repeated whenever something changes, enables threat modeling to remain fast and continuous.

When it comes to testing, you should test like attackers would. “We throw malicious prompts, poisoned data, and guardrail-breaking attempts at our AI systems before release,” he says. “If our AI misbehaves, we fix it before anyone else can exploit it.”

Make it zero-trust!

AI helps defenders, but it also helps attackers. Adaptive phishing, deepfakes, and model inversion attacks are no longer hypothetical – they’re real. Roland advocates for a layered defense strategy that combines privacy-preserving techniques, governance frameworks, and culture change.

For model inversion, he points to regularization techniques, API access controls, and specialized defenses such as trapdoors to misdirect attackers.

However, data discipline matters just as much: teams minimize personal data, de-duplicate records, and apply strong consent and retention policies before training models. On the human side, Roland is blunt:

Make it zero-trust. Strong login, least privilege, and constant verification for people, services, and AI models.

His team conducts frequent, audience-tailored awareness sessions and real-world drills, ranging from deepfake scenarios to phishing simulations, so that employees can recognize emerging threats.

Strict communication rules help as well: sensitive actions like payments, access changes, and data requests must go through verified channels with two-person approval, never via informal messages or DMs.

If a request is urgent and secret, slow down. We give staff explicit cover to pause and verify even if it is “the CEO” on the line.

Security isn’t a cost center – it’s a revenue enabler

Roland emphasizes measurement as the bridge between technical controls and leadership buy-in. He recommends tracking metrics such as time to close deals, incident rates, audit duration, and verification rates before taking high-risk actions. Mapping controls to established frameworks, such as CIS Controls v8, NIST 800-53, and ISO 27001/27002, streamlines audits and makes funding more defensible.

When you can prove that certifications and clear proof of controls shorten sales cycles and open partnerships, suddenly security isn’t just a cost center. It’s a revenue enabler.

Treat the pipeline like production

As AI accelerates software delivery, the CI/CD pipeline has become the beating heart of modern development, but it has also become an increasingly attractive target for attackers. Roland warns that organizations can’t afford to treat their delivery pipelines as second-class citizens.

Treat the pipeline like production. It runs the factory, protect it like crown jewels.

Securing automated delivery flows starts with proof, not trust. Only signed code, images, and models are allowed through. “If it isn’t signed, it doesn’t ship,” he emphasizes. The system automatically scans dependencies, containers, secrets, and cloud configurations, and it halts the build immediately when it finds critical issues.

Teams isolate access using short-lived tokens and separate runners, eliminating the need for “kubectl from a laptop” shortcuts. The pipelines themselves are under constant surveillance.

Alert on strange runner behavior or workflow changes. If something looks off, pause and investigate before it spreads.

Track behavior, not just components

This rigor extends beyond internal code. As AI ecosystems grow more interconnected, the supply chain, spanning third-party libraries, pretrained models, datasets, and vendors, has become a prime target for sophisticated attacks. Roland advocates for a “trust, but verify” posture.

Track what’s inside. Ship an SBOM with every release, apps, containers, and model bundles, so you know every ingredient.

Teams must sign and verify every artifact, from model files to data packages, before using it. Teams don’t take third-party components at face value; they vet vendors for lineage, update habits, and incident history, and they require formal attestations.

Pretrained or open-source models are quarantined by default until they are scanned, wrapped, and continuously monitored for security vulnerabilities. Once the system is in production, teams can track behavior in real-time.

Don’t just list components, watch what they actually do.

Classify your AI by risk

With the EU AI Act and new data protection laws reshaping the regulatory landscape, Roland sees compliance not as a scramble at launch but as an architectural principle.

Design for the EU AI Act and friends from day one. Classify your AI by risk, attach the right controls, and plan human oversight where it is required.

This regulatory-first mindset drives concrete engineering practices: teams bake data minimization and purpose limitation into schemas and pipelines, not just policy documents. Model cards, decision logs, and clear appeal paths make AI decision-making explainable for both auditors and end users. Teams maintain immutable logs and model lineage with retention policies that align with legal obligations.

Be audit-ready, always. It’s much cheaper than retrofitting compliance later.

Get all signals in one place

As attackers adapt their tactics in real time using AI, defensive strategies must also become equally dynamic. Roland emphasizes the importance of observability, telemetry, and AI-driven defense in detecting anomalies before they escalate.

“Get all signals in one place,” he says. Teams aggregate logs from endpoints, identity systems, APIs, data jobs, and models into a single observability layer. Crucially, security teams monitor not just applications but the models themselves, tracking drift, unsafe outputs, and suspicious prompt behavior.

Detection should be trained on your own operational environment rather than generic threat baselines, so anomalies stand out quickly. When something triggers, automated playbooks in SOAR systems can take immediate action: isolating systems, rotating secrets, revoking tokens, or rolling back versions within minutes.

You can’t wait for a human ticket queue when the attack is adapting on the fly.

Make security a team habit

For all the technology and governance, Roland insists that the real force multiplier is culture. Security can’t live in a silo, it has to become a team habit.

Plant security champions in every squad. Peer-to-peer help beats one central bottleneck.

Regular tabletop exercises tied to real-world projects, such as handling deepfake scams, leaked credentials, or prompt injection attacks, keep teams alert and well-practiced.

Teams can also use positive reinforcement: they can celebrate clean audits, sharp threat models, and early bug catches publicly. To make good behavior the default, Infobip provides “paved roads,” opinionated templates, and secure defaults that make the safe path the easiest one.

With these layered strategies Roland is helping redefine what “secure AI” looks like in practice.

Security isn’t a brake on innovation. It’s what lets you innovate safely and keep that advantage.

The post Want Better Security? Test Like Attackers Would appeared first on ShiftMag.

The CAMARA open-source project delivers standardized APIs for network functions. Developers can now use network features as easily as any REST API. This is not a pilot experiment. Dozens of operators worldwide already support Open Gateway.

The CAMARA community now counts over 47 companies and thousands of experts. Standardization ensures the same API works across borders and operators. Developers can build applications that scale globally and stay portable and scalable.

At this year’s Infobip Shift conference, the panel “Unleash the Power of 5G in Your Code: Transform Your Apps” highlighted a significant shift for developers — bringing the network directly into their code. Korrey Sutherland (GSMA), Markus Kümmerle (CAMARA), and Cedric Gonin (Orange) shared a clear message: it’s time to unlock the power of 5G networks and put it directly in developers’ hands.

Korrey Sutherland

What 5G Networks Can Do for Applications

The panel showed practical cases of a codable network. In insurance, a user reports an incident, accompanied by a photo and GPS data. The API validates the claim, reducing the risk of fraud.

Infrastructure projects also benefit. Operators can use network data to monitor road conditions or guide new developments. Public sector use cases include identity protection and safety measures for children in schools.

One of the most powerful demonstrations came from remote vehicle control. A car in Finland responded in real-time to commands sent from Barcelona, over 3,400 kilometers away. The 5G network and API enabled this with ultra-low latency and reliable connectivity.

Cedric Gonin from Orange added business examples. Companies now process requests more efficiently with APIs, including digital document checks and real-time risk assessments in insurance.

Cedric Gonin

Behind all this progress stands CAMARA. As an open-source project under the Linux Foundation, it standardizes APIs and hides complexity. Developers don’t need to study network architecture or operator differences.

They utilize simple interfaces that are compatible with any device. The result is application portability, faster launches, and entirely new user experiences. The network no longer acts as background infrastructure. It becomes an active tool inside applications.

From Vision to Reality

What once sounded like a vision is now a reality in practice. GSMA Intelligence reported that by mid-2025, over 70 operator groups with nearly 300 networks had joined Open Gateway.

That accounts for approximately 80 percent of the global mobile market. Meanwhile, CAMARA expanded its API library to dozens of use cases. These include identity, location, authentication, quality-on-demand, and edge computing.

Some countries already deploy these APIs. In the UK, operators rolled out age verification and SIM swap protection. In Indonesia, telcos use unified API standards for device security and validation. Developer portals now display which APIs are supported in which countries. Interactive maps, clear docs, and testing tools lower the barrier to entry.

Markus Kümmerle

Developers can focus on value and innovation instead of struggling with network integration. The message is clear. The network is open.

Developers must seize it. With GSMA Open Gateway and CAMARA, applications no longer rely only on the cloud. They can now tap directly into the network. It’s time to unleash the network in your code. Only then will applications reveal what 5G networks can achieve in practice.

Want to know what else was discussed at Infobip Shift at Zadar in 2025? Find out here!

The post $300B Opportunity: 5G APIs Put Networks in Developers’ Hands appeared first on ShiftMag.

Meet Branded Caller from Infobip.

Unlike regular caller ID that might flash a name (or worse, just a number), Branded Caller puts verified, visual brand info front and center. Think: the company’s logo, a recognizable display name, and even a quick note about why they’re calling. No more mystery calls.

For developers, this isn’t just a nice-to-have feature – it’s a serious upgrade to the voice call experience.

By integrating Branded Caller, you’re helping businesses increase answer rates, build trust, and fight fraud, all while working inside a secure and standardized ecosystem built for interoperability and long-term use.

Why developers should care about branded calling?

With call fraud on the rise in the U.S., Branded Caller has stepped up by using cryptographic security under the STIR/SHAKEN protocol to verify caller numbers and significantly reduce spoofing and robocalls.

As Ryan McQueary (Manager of Voice Engineering, Infobip) explains, STIR/SHAKEN is a set of industry standards that enhance call verification by cryptographically signing voice calls – a critical step for ensuring call authenticity.

Here’s how it works from a technical standpoint:

When a call is placed, the originating service provider sends a verification request to an Authentication Service (AS). This request includes key details like the originating and receiving phone numbers, timestamp, and an important metric called the trust level or Attestation Level.

This trust level indicates how reliable the call is:

• Both the network and caller are trusted.
• The network is trusted, but the caller is not.
• Neither the network nor the caller is trusted.

The Authentication Service then returns an Identity Header, which includes a cryptographic signature and certificate. This data travels along with the call through the phone network. Before the call reaches the recipient, the terminating provider verifies this signature and trust level.

Based on the verification results, the provider can decide to mark the call as “trusted,” block it, label it as “SPAM Likely,” or flag it for further action.

For developers, this process offers a powerful way to build secure, trusted communication apps and services that can help businesses reduce fraud while improving customer trust and engagement.

STIR/SHAKEN – one protocol to rule them all

Early branded calling systems, or “legacy” approaches, explains McQueary, relied on a patchwork of databases, carrier deals, and handset partnerships. They showed logos or caller names but were fragmented, lacked cryptographic security, and varied in accuracy across networks and devices.

Legacy systems didn’t securely embed branding into call signaling, and before STIR/SHAKEN, there was no standard way to transport and validate branding across carriers – making calls vulnerable to tampering.

STIR/SHAKEN changes all that.

It builds a higher level of trust for carriers and users by ensuring the displayed brand identity stays legit and can’t be easily faked.

And because STIR/SHAKEN is based on industry – wide standards, it works seamlessly across carriers, mobile systems, and networks. Regulators, carriers, and standards bodies back it as the universal solution, making cryptographically signed branding more trusted wherever calls go.

How do I wire Branded Caller into my stack?

So, how do you plug Branded Caller into your existing setup, and what’s needed to make it work?

First off, Infobip acts as the Originating Service Provider and signs calls using a Signing Agent from the CTIA ecosystem. They picked SecureG to handle this crypto magic, making sure calls are legit and trusted.

Next, they team up with an Onboarding and Vetting Agent, NumHub, which lets customers securely add their brands to the mix. Think of it as the bouncer making sure only the right brands get in.

Security’s no joke here, Infobip runs a strict KYC (Know Your Customer) check before handing out Virtual Local Numbers. They follow CTIA’s standards to keep everything reliable and above board.

And it’s not just about old-school phone calls (PSTN). Infobip also supports cool OTT channels like Viber Business Calls and WhatsApp Business Calling, showing off verified business names and logos. That way, businesses can reach customers wherever they’re most likely to pick up.

Want to learn more about Branded Caller? We’re here to help!

The post Developers, Make Your Calls REALLY Legit with Branded Calling appeared first on ShiftMag.

So, the idempotency… What does it even mean and what makes something idempotent? Is it really that important for good architecture?

Adrienne Braganza Tacke, software engineer, and keynote speaker, explains this ‘secret ingredient’ and shares tools to help make your requests, APIs, or functions idempotent.

Explanation of idempotency – in simple words!

Adrienne shares an example: “My husband and I are on a road trip, and I want to order a cake from a bakery in Las Vegas. I lose a network connection in a tunnel right after placing the order. When I regain connection, I resubmit the order, thinking it didn’t go through the first time. Without idempotency, I end up with two cakes, even though my intent was to order only one.”

This is a simple example, but imagine this happening with something more serious – bank transactions or other critical operations.

So, idempotent in tech means that a certain operation can be applied many times, without changing the result. The lack of idempotency means the system cannot capture the true intent of a request, leading to harmful side effects like duplicate charges or withdrawals.

Idempotency is key to mitigating side effects while solving problems

And what does idempotency have to do with good architecture? According to Adrienne, it has everything to do with it.

Have you heard about the seven design principles of well-architected applications? These principles are:

1. Speedy,
2. Simple,
3. Singular (meaning focusing on doing a single thing at a time),
4. Sharing nothing, specifically in serverless (assuming no state or information sharing between servers),
5. Assuming no hardware affinity,
6. Using events to trigger transactions rather than function chaining,
7. Thinking about concurrent requests rather than total requests.

And the most important one here, claims Tacke, is designing for failures and duplicates. Without idempotency, says she, this principle is impossible to uphold. “Failure is always going to happen. If we keep that in mind, we develop our applications differently, considering edge cases, error handling, and how to deal with inevitable failures.”

So, failures lead to retries – we’ve been solving problems by trying something again, resending something, or turning it on and off again, knowing that retries are part of our toolbox means we need to understand that duplicates can and will occur.

If we’re the ones implementing retries, we are potentially introducing duplicates into our system. And that’s okay, as long as we handle it properly. This is where idempotency is key to mitigating side effects.

How to apply this in our projects?

Adrienne offers three key elements to apply idempotency: an idempotency key, an idempotency layer, and persistent storage.

1. Idempotency Key: This is usually generated by the client and uniquely identifies each request. It could be a unique identifier, a hash of the event, or a timestamp.
2. Idempotency Layer: This acts as a filter in the API layer, deciding what to do with the request by checking if the key has been seen before.
3. Persistent Storage: This stores the state and acts as the source of truth, allowing the idempotency layer to determine whether the request has been processed.

“Applying these, let’s revisit our bakery example. When I place an order, an idempotency key is generated and sent with the request. The API checks this key against persistent storage. If the key hasn’t been seen before, the order is processed, and the result is stored. If the request is retried, the API sees the key, recognizes it, and prevents duplicate processing, ensuring my intent is honored.”

And if you want to try idempotency, AWS Lambda Power Tools is a great resource. They have implementations for TypeScript, .NET, Python, and Java. This library includes features like preventing multiple executions of the same payload during a time window and handling concurrent executions. It uses persistent storage, like DynamoDB, to track idempotency keys and states, making it easier to debug and manage.

She adds that other tools and libraries include Stripe’s API, which has excellent documentation on implementing idempotency, and the idempotent API library for .NET solutions, which uses idempotent decorators to add idempotency to APIs. Finally, Cisco also has products using idempotent requests.

The post Learn about idempotency – the key ingredient for reliable APIs appeared first on ShiftMag.

Not long ago application and API security relied solely on manual methods like knights guarding a castle.

Now, with Agile and DevOps leading the charge and orchestrated ephemeral infrastructure as our new arsenal, we’ve upgraded to a tech-savvy defense, ensuring efficiency and effectiveness like never before.

In this interview, we talk about it with Larry Maccherone, Dev[Sec]Ops Transformation Architect at Contrast Security.

There are almost no dedicated QA departments anymore

“Back in the early days of Agile, I used to advocate for cross-functional teams owning software products, including quality. After these talks, QA professionals would often express concern about their siloed roles, fearing changes if development teams took over quality responsibility, often commenting, “What you said sounds idealistic. It’ll never work at my organization. The developers will just put out crap.”

A decade later, there are almost no dedicated QA departments, and the ones that are left are more of a body shop with all of their people on semi-permanent ‘loan’ to specific dev teams.

Also, we have to remember that back then, developers didn’t do QA the way QA people did QA. “They tried to eliminate all manual testing and replace it with automated testing.”

The DevOps and cloud-native movements were similarly disruptive to traditional IT Ops and were also dominated by automation. Security is now well into a similar tradition which is also marked by more tools deeply integrated into the process.

Shifting the responsibility for security to dev teams

We also asked Larry about the challenges that the industry faces when considering application and API security as a siloed function.

“Siloed functions tend to result in local optimization rather than holistic systems thinking. In systems thinking (referred to as “flow” as the first of three “ways” of DevOps), you try to optimize for value delivery of the entire software development system”, Larry claims.

To get more concrete, Larry says that in a silo, security folks find the vulnerabilities, but they can’t fix them themselves. That leaves them in the position of essentially begging the developers to fix them.

“In this same siloed example, the development teams are measured on how many features they ship. Security is responsible for security. So, the local optimization is to ignore the requests from security to fix the vulnerabilities they found.”

On the other hand, if you shift responsibility for security to the development team, they can optimize for the best overall outcome. Sometimes that means, they can make tradeoffs. At times they might legitimately decide that the risk of not fixing a vulnerability is outweighed by the risk of missing a market opportunity. At other times, they will decide that the security vulnerability fix is the most valuable way to spend their limited resources.

Also, according to Maccherone, developers are prone to automate things, which makes them more efficient overall.

Developers just want their code to be merged

A particular practice that is now universally used by development teams is the pull/merge request. It is the very center of how development teams coordinate their work.

It’s the process of a developer’s morning work reaching the shared codebase by afternoon and ultimately going into production. Almost all automated quality and security checks can (and should) be run prior to the decision to merge that code.

The person clicking on the “merge” button is generally a teammate of the developer for that pull/merge request.

This pull/merge request reviewer, will look at the changes but will also be informed by the automated quality and security checks that were run prior to their review.
Developers are passionate about the code they wrote and want nothing more than for it to be merged. They will see any negative feedback from a security check and respond to it immediately.

Done this way, the vulnerability is often resolved on the same day that it was injected. At this point, the code is very familiar to the developer, so the cost of fixing is an order of magnitude lower, especially when you consider that there was no vulnerability inventory carrying costs.

The situation Larry described above is only possible if each pull/merge request has its own isolated infrastructure for the automated quality and security checks to run.

With traditional methods, having five developers on one team would require maintaining five separate test environments, costly and often idle. Yet, with container-based ephemeral infrastructure, a single developer’s request can spawn multiple workers to conduct quality and security checks simultaneously, completing tasks rapidly and freeing up resources for others.

Technology, practices, and culture

And what about a future Larry sees emerging for application and API security testing?

He emphasized that significant industry transformations, such as the DevOps movement, hinge on three key components: technology, practices, and culture.

In DevOps, ephemeral build and test infrastructure alongside cloud-native technologies represent the technological shifts, while adopting the pull/merge request signifies a change in practices. Culturally, the pivotal shift involves transferring operational responsibilities to the development team.

So, what is the coming revolutionary change for Application and API Security?

It follows the revolution pattern for DevOps, namely those three things – technology, practices, and culture, but it also builds upon the changes that DevOps has brought.

However, before we jump into it, we are going to take a little detour to one discipline that fundamentally changed along with the DevOps movement: performance testing.

Performance testing in production: cheaper, faster, and safer

“Performance testing was long considered a necessary evil. It was expensive and inaccurate, but without it, you ran the risk of having an outage or at least annoyed customers when your application appeared non-responsive.”

Creating a test environment similar to production was necessary, but the closer it mirrored reality, the higher the costs, potentially doubling production expenses.

Then, running extensive automated test scripts in the performance environment incurred high costs, but the real issue was their reliance on artificial traffic, which would lead to inaccurate predictions of real user performance.

“Because of these difficulties, many didn’t even bother with performance testing and took the risk of releasing without it,” Larry says.

Then came technology, practice, and cultural transformations that disrupted the performance testing landscape and avoided all the previous problems. Developers started doing performance testing in production.

The enabling technological change came in the form of application performance monitoring agents that were efficient enough to run in production. The practice change was canary deployments. The cultural shift was realizing that doing performance testing in production was cheaper, faster, and safer than doing it in pre-production when we previously believed you must trade these factors off against each other.

Test your API security in production too

At this point, you might be thinking, “What does this performance testing diversion have to do with the future of application and API security testing?”

Well, what if we can safely accomplish app and API security testing in production?

Doing so avoids the downsides of the current methods:

• SAST’s inaccuracy and long scan times
• DAST and IAST’s poor coverage
• SCA’s lack of context
• WAF’s ineffectiveness

“Like the performance testing of yesteryear, these downsides, along with the cost of licensing, rolling out, and maintaining all of these disparate tools, cause many to skip some or all of them and risk getting hacked. However, to achieve a revolution like this, we’ll need all three elements of the other revolutions: technology, practices, and culture,” Larry emphasizes.

The technological innovation we need is the same as the one we need for the performance testing revolution – agents that are safe and efficient enough to run in production. We’ve been making steady improvements to our IAST agent for years such that it’s an order of magnitude more efficient than it was a few years ago, but we recently beta-released new agents that take a fundamentally different approach when running in production environments, which have improved the efficiency by another order of magnitude.

The practice change is that we need those agents installed by engineering teams in production environments. The cultural transformation is similar to the performance testing one—the conviction that doing application and API security testing in production is cheaper, faster, and more secure than doing it in pre-production.

So, Larry believes we are on the cusp of a revolution in app and API security testing like the one that occurred for performance testing.

The post “Developers should own security. And test in production.” appeared first on ShiftMag.

StackOverflow considers it against the collective collaboration nature of their community and causing significant disruptions to the site.

The freshly announced StackOverflow and OpenAI partnership will allow the AI company to “improve its AI models using enhanced content and feedback from the Stack Overflow community and provide attribution to the Stack Overflow community within ChatGPT.”. 

Translated from corporate lingo – the partnership will allow OpenAI to access the years and years of StackOverflow’s community contributions to train its AI model. Many users are unhappy with their answers being used to train AI and have started deleting them.

Some users have shared emails they got from StackOverflow, which banned them from the site for seven days because deleting contributed content causes “a lot of disruption” and warns them against further deletion. As much as the users are angry about it and claim they have the right to manage the content they created, StackOverflow’s Terms of Service contain a clause that states they have irrevocable ownership of all content members provide. 

The public announcement of the partnership does mention that it will enable ChatGP to provide attribution to the Stack Overflow community. Still, long-time StackOverflow users doubt the developer community’s sincerity regarding AI, as they have already changed their minds. 

For the last two years, StackOverflow has been trying to downplay the significance of AI tools and prove their supremacy in providing knowledge to developers compared to ChatGPT – they have even launched their own AI product, OverflowAI, in an attempt to counteract developers flocking to get instant answers from ChatGPT instead of searching on StackOverflow.

They have started praising the power of AI tools lately and a new set of new integrations and capabilities between Stack Overflow and OpenAI have been announced as part of this partnership that will be available in the first half of 2024. 

The post Do not delete: StackOverflow bans users protesting their OpenAI partnership appeared first on ShiftMag.

Mary Thengvall, Director of Developer Relations at Camunda, Matt Billman, CEO & Co-founder at Netlify, and Eric Schabell, Director of Technical Marketing & Evangelism at Chronosphere, are just some of the highly coveted pioneers and innovators within the global developer community who will take the stage at the iconic Perez Art Museum.

With over 500 attendees expected in 2024, Infobip Shift Miami is poised to solidify its place as a beloved annual gathering within the American developer community.

This year’s Infobip Shift Miami expands on the success of last year’s event. We’re dedicating a full day to lectures and panels, with networking on day one and hands-on workshops on day three.

Nikola Radišić, Head of the Infobip Shift team

Expanding its horizons, the conference now shines a spotlight on software with a thematic focus. This spotlight centers around APIs, the backbone of swift and seamless software operation. These APIs are not just vital; they’re indispensable tools for developers across various industries. Radišić says:

We chose to hone in on APIs due to their status as a burgeoning and incredibly vital sector within the software industry – an indispensable component for envisioning a modern developer profession. We aim to provide the audience with insights into the latest tools and solutions, empowering them to optimize their skills and stay ahead in the world of software development.

By expanding the program in this year’s edition, we cement our commitment to connecting and supporting developers worldwide.

Nikola Pavešić, Director of Developer Experience and Startups at Infobip

Get your ticket!

Calling all developers, tech aficionados, and industry experts!

Win a ticket for Shift Miami, from April 22nd to 24th, 2024.

The post Win 1 of 15 tickets for Shift Miami 2024 – and explore APIs! appeared first on ShiftMag.