APIM

Your AI agent depends on a chain of services. In my side project (Biotrackr), the chain looks like this: Claude API for reasoning, APIM for routing, downstream APIs for health data, and Cosmos DB for chat history. When one link in that chain fails, things can get ugly fast. Imagine this: Claude API returns a 429 (rate limited). The agent retries the same request. Each retry consumes more tokens. More 429s. The conversation times out. The user sees an error and submits again, doubling the load. A single rate limit hit has cascaded into a degraded experience, wasted tokens, and a frustrated user (in my case, just me screaming at my own agent 😅 For you however, that would be your customers!). ...

Biotrackr is a single-agent system. One agent, twelve tools, one identity. That is an architectural choice that eliminates an entire vulnerability class Insecure Inter-Agent Communication (ASI07). But what happens when the system grows? Imagine Biotrackr evolves into a multi-agent platform: a Data Retrieval Agent that fetches health records, a Health Advisor Agent that provides wellness recommendations based on trends, and an Orchestrator Agent that coordinates them. Suddenly, agents are talking to each other, passing data, delegating tasks, sharing context. Every message between them is a potential attack surface. ...

Every time your AI agent saves a conversation, you’re creating a potential attack vector. ASI06 (Memory and Context Poisoning) asks a deceptively simple question: “can previous conversations corrupt future ones?” For my side project (Biotrackr), this is one of the more interesting risks. The chat agent persists conversation history to Cosmos DB, and those persisted conversations become context when a user continues an old chat. A poisoned message from 2 weeks ago could influence today’s analysis. The IMemoryCache used for tool response caching is shared across sessions. A cached response could influence a different session’s results. ...

Your AI Agent’s security is only as strong as its weakest dependency. Whatever packages you are using within your agents, you’re trusting that those packages that have been published haven’t been tampered with and that they don’t contain vulnerabilities. The same applies for every transitive dependency in your graph. In Biotrackr, I’m using a couple of packages that are still in preview, so there may be flaky APIs that could affect my agent’s security and reliability. Agentic Supply Chain Vulnerabilities are amplified in agents because AI frameworks are in preview (at time of writing). The technology is evolving rapidly, and these frameworks have deep dependency trees that are harder to audit. ...

One of the challenges I faced developing an agent for my side project (Biotrackr) was how do I manage identity. Some AI Agents share the same service principals or managed identity with the application, which is used to authenticate API calls, access databases etc. This is an issue, because if the application has contributor access to a database, so does the agent. If the agent gets compromised, then the blast radius extends to the entire application’s permission scope. ...