When you type a prompt, you summarize. When you speak one, you explain. Wispr Flow captures your full reasoning — constraints, edge cases, examples, tone — and turns it into clean, structured text you paste into ChatGPT, Claude, or any AI tool. The difference shows up immediately. More context in, fewer follow-ups out.

89% of messages sent with zero edits. Used by teams at OpenAI, Vercel, and Clay. Try Wispr Flow free — works on Mac, Windows, and iPhone.

Start flowing free

Imagine a typical Series C Agentic Operations platform: a beautiful architecture deck with clean boxes for an Orchestrator, Salesforce Agent, and Jira Specialist, all tied together with function calling. It looks perfect until you look at the security model. What happens when a prospect sends a prompt injection inside a calendar invite that the agent automatically processes? If the system goes silent, it's because the architecture isn't just an integration it's a privilege escalation ladder waiting to be exploited

We are currently witnessing a mass adoption of the "Manager-to-Agent" pattern, popularized by OpenAI's own deployment guides. It feels intuitively correct to engineering leaders: you create a central orchestrator that delegates tasks to specialized sub-agents. It's clean, it's modular, and it's fundamentally broken from a security perspective.

The flaw lies in the call chain. In this architecture, the manager treats the output of a sub-agent as trusted data. If a specialized agent responsible for reading emails or scanning calendar invites is compromised via indirect prompt injection. A well documented vulnerability where malicious instructions are hidden in external data it passes a poisoned function result back to the manager. The manager, operating with the elevated permissions required to coordinate across systems, executes the next command in the chain. We are essentially repeating the confused deputy problem at an autonomous scale. Google Gemini flaws have already demonstrated this: calendar invites could trigger unauthorized data exfiltration. If your orchestrator cannot distinguish between a trusted instruction and a poisoned function result, you aren't building a system; you're building a liability.

Traditional IAM was built on the assumption that a human is the ultimate arbiter of an action. When we move to autonomous function calling, that assumption evaporates. I've looked at the logs of early-stage enterprise AI deployments, and they are a compliance nightmare. Every action from deleting a record in Salesforce to updating a production config is attributed to a single, monolithic service account: ai-agent-prod.

This is the Who Authorized This? problem. When an agent calls a sensitive API at 3 AM, your existing stack cannot tell you if that call was a legitimate response to a user's previous session or a hallucinated byproduct of a corrupted context window. Workload Identity Federation for AI is a term vendors are starting to throw around, but let's be honest: it doesn't exist in a usable form for most of us yet. Without a direct, cryptographic link between a specific human session and the downstream function calls made by an agent, you have zero accountability. You are flying blind in your own production environment.

Beyond the security risks, there is the silent killer: context pollution. In a traditional software stack, a bug in a function returns an error, and the process stops or retries. In an agentic system using function calling, a bug is often a hallucinated API response that looks perfectly valid. An agent might "decide" a customer balance is -$1M because it misread a poorly formatted JSON response.

That single piece of corrupted data now poisons every subsequent step in the conversation. Every downstream function call is now being made based on a lie. Unlike the deterministic bugs we've spent decades learning to squash, these are probabilistic and nearly impossible to reproduce in a standard QA environment. Teams are relying on State Rewind features, but those are useless if a human doesn't catch the error in real-time. By the time your monitoring alerts go off, the agent has already made forty-seven more calls based on that initial hallucination. This isn't just technical debt it's architectural rot that settles in seconds.

We're seeing a lot of excitement around the Model Context Protocol (MCP) as a way to modernize legacy APIs by wrapping them for LLM discovery. It sounds like a great way to unlock value from that ten-year-old SOAP API or the internal database that's been hidden behind a firewall.

In reality, you are just expanding your attack surface to anyone who can send an email to your employees. By making these legacy systems "discoverable" and "callable" by an LLM, you are removing the layers of security by obscurity and manual gatekeeping that kept them safe for a decade. An LLM is socially engineerable. If that LLM has a direct line to your legacy ERP system via an MCP wrapper, you have effectively turned every phishing attempt into a potential API breach. We are treating data as code all over again, and we are doing it with systems that were never designed to handle the complexity of autonomous interaction.

The problem is clear: enterprises are implementing AI function calling as a simple API integration, ignoring that it creates a new class of autonomous, non-deterministic security vulnerabilities and "context pollution" that traditional IAM and QA cannot handle.

The fix requires shifting from trusted orchestrators to a zero-trust execution model. This means mapping every agent-initiated function call back to an original human session token and implementing circuit breakers that validate function outputs against hard business logic before they return to the LLM context.

You'll need existing OAuth2 or OIDC infrastructure, a centralized API Gateway (Kong, Apigee, or similar), and structured logging with trace ID propagation across LLM calls. The real work is policy-level: implement a "Human-in-the-loop" (HITL) requirement for any function call categorized as Mutating or Sensitive. Use a secondary, deterministic validation layer that checks the LLM's requested action against a pre-approved policy set tied to the original user's permissions, not the agent's service account.

The immediate risk is indirect prompt injection where an agent reads a malicious document or email and executes a Delete or Exfiltrate function call. Your audit logs today cannot catch this because they don't track the session-to-action relationship. That needs to change before you push any of this to production.