What is AI agent development?
AI agent development is the discipline of designing, building, testing, and deploying AI systems that can autonomously pursue goals by reasoning about problems, planning actions, and executing tasks using tools and external services. This matters right now because agents are rapidly moving from research demos into production cloud workloads that interact with real data, real infrastructure, and real users, introducing development and security challenges that traditional software engineering was never built for.
It helps to be clear about what agent development is not. Building a simple LLM chat application, where a user sends a prompt and gets text back, is not agent development. Neither is writing traditional if-then automation scripts. An AI agent combines an LLM with memory, tools, data access, and decision-making logic that determines its own next steps. The LLM acts as a reasoning engine, not just a text generator.
According to the Wiz State of AI in the Cloud 2025 report, 85% of organizations now use AI services or tools, and agent-based architectures are among the fastest-growing patterns in cloud environments. The shift is significant: traditional automation follows fixed rules written by developers, while AI agents use LLMs to interpret situations and decide what to do next. That flexibility makes them powerful, but also less predictable and harder to secure.
Securing AI Agents 101
This one-pager explainer breaks it all down: What makes something an AI agent, where risk emerges (and why it’s hard to see), practical steps to reduce exposure, and what teams can do to secure AI pipelines.
Why AI agent development matters now
AI has moved from "ask a question, get an answer" to "define a goal, let the agent figure it out." This shift from static LLM applications like chatbots and summarizers to autonomous agents that take real actions in production changes what developers build and what security teams need to protect.
The explosion of agent frameworks (like LangGraph, CrewAI, Google ADK, and AutoGen) along with protocols like Model Context Protocol (MCP) has dramatically lowered the barrier to building agents. More teams are shipping agents faster, often without established security review processes or centralized governance.
The business drivers are clear: agents automate complex agentic workflows across customer support, code generation, data analysis, and internal operations. But agents that act autonomously also make autonomous mistakes, and those mistakes carry real consequences when agents hold credentials to production systems.
As agents become cloud workloads with their own identities, network access, and data connections, the gap between what development teams build and what security teams can see keeps widening.
Consider a developer who spins up a coding agent that connects to a code repository, a cloud deployment pipeline, and a database. That agent now has access to source code, production infrastructure, and potentially sensitive data, all through a single set of credentials that may never get reviewed by a security team.
Organizations that treat agent development as purely an AI problem, rather than a cloud infrastructure and identity problem, are creating dangerous blind spots.
How do AI agents work?
An AI agent is built from a few key components that work together in a continuous loop. Understanding these building blocks is essential before you choose frameworks or write code.
| Component | What it does | Example |
|---|---|---|
| LLM (reasoning engine) | Interprets inputs, plans actions, decides next steps | GPT, Claude, Gemini |
| Tools / function calling | Lets the agent interact with external systems | API calls, database queries, code execution |
| Memory | Stores context across interactions (short-term and long-term) | Conversation history, vector databases |
| Orchestration logic | Controls the agent's decision loop and workflow | LangGraph state machine, prompt chaining |
| Data connections | Feeds the agent information it needs to act | RAG pipelines, knowledge bases, training data |
| Identity / credentials | Authenticates the agent to external services | Cloud IAM roles, API keys, service accounts |
These components work in a repeating cycle: the agent perceives an input, reasons about it using the LLM, plans its next action, acts by calling a tool or API, observes the result, and repeats. For example, an agent that triages customer support tickets would read the ticket, query a knowledge base using retrieval-augmented generation (RAG), check the customer's account status via an API call, and route the ticket to the right team, all without human intervention.
Each component in this architecture also represents a potential point of failure or security exposure. Tools need authentication. Memory stores may contain sensitive data. Orchestration logic determines what the agent is allowed to do. This is why agent development is not just an AI problem; it is a cloud infrastructure, identity, and data security problem simultaneously.
Key design patterns for AI agents
Not every use case needs a fully autonomous agent. The best agent developers choose the simplest pattern that solves the problem, and only add complexity when the simpler approach falls short. Anthropic's guide to building effective agents popularized this pattern-based thinking, and it has become the standard way practitioners approach architecture decisions.
Prompt chaining
Break a task into fixed steps where each step's output feeds the next. This pattern is simple, predictable, and easy to debug. It works best for well-defined workflows where the sequence of actions is known in advance, like a content review pipeline where step one extracts key claims, step two fact-checks each claim, and step three generates a summary report.
Routing
Classify an input and direct it to a specialized handler. This pattern works well for agents that need to handle diverse request types, like a support agent that classifies incoming tickets as billing, technical, or account issues and routes each to a different specialized prompt or tool set.
Tool use and function calling
The LLM decides which tools to call and with what parameters. This is where agents gain real-world capabilities, and also where the most significant security considerations emerge. Tool use is the inflection point where an agent goes from "thinking" to "doing," and that transition is where most security risks concentrate. An agent that can call arbitrary APIs or execute arbitrary code needs carefully scoped permissions.
Orchestrator-workers
A central LLM breaks a task into subtasks and delegates to specialized workers. AI agent orchestration is useful for complex, multi-step problems where the subtasks are not known in advance, like a research agent that receives a broad question, breaks it into sub-questions, assigns each to a worker searching different data sources, then synthesizes the results.
Multi-agent systems
Multiple agents collaborate, each with distinct roles and capabilities. This pattern is powerful but harder to debug, secure, and monitor because each agent may have its own identity, tool access, and data connections. Most production use cases do not need multi-agent architectures. Starting simpler is almost always the right call, since the overhead of coordinating multiple agents is only justified when a single agent genuinely cannot handle the task.
AI agent development frameworks and tools
The framework ecosystem is moving fast, and the right choice depends on your use case, team expertise, and production requirements.
LangGraph: Graph-based orchestration for complex, stateful agent workflows with conditional branching and persistent state across steps.
CrewAI: Role-based multi-agent collaboration framework that simplifies building systems where multiple agents take on distinct personas.
Google Agent Development Kit (ADK): Code-first framework with deep Google Cloud integration, designed for enterprise teams connecting agents to Google services.
AutoGen: Microsoft's multi-agent conversation framework, strong for research and prototyping conversational multi-agent systems.
Pydantic AI: Type-safe agent framework emphasizing structured outputs and strict data validation on agent inputs and outputs.
Model Context Protocol (MCP): Open protocol for connecting agents to tools and data sources in a standardized way, similar to how USB standardized hardware connections.
Framework selection also has security implications. Frameworks that make it easy to grant agents broad tool access or connect to arbitrary MCP servers require more careful governance. Understanding what each framework allows the agent to do by default is a critical part of the selection process. The landscape changes rapidly, so evaluate community activity, documentation quality, and the vendor's approach to security defaults alongside current features.
Inside MCP Security: A Research Guide on Emerging Risks
The Wiz research team has been investigating how MCP is being used today and where early adopters may be exposed. This guide breaks down the most pressing risks and offers practical steps to secure MCP as it evolves.
How to build an AI agent: a step-by-step process
Building an AI agent follows a structured process, but unlike traditional software, each step has unique considerations because agent behavior is non-deterministic. These steps reflect how production-grade agents are actually built.
Step 1: Define the goal and scope
Start with the problem, not the technology. What specific task should the agent accomplish? What data does it need, and what should it never touch? Scoping is also a security exercise: defining what the agent should not do is as important as defining what it should do.
Step 2: Design the agent architecture
Choose the right design pattern and map out the tools, data sources, and orchestration logic. This is also where you define the agent's identity: what cloud services it will authenticate to and with what permissions. Decisions made here determine the agent's blast radius if something goes wrong.
Step 3: Select frameworks, models, and tools
Choose the LLM, orchestration framework, and tool integrations. Every model provider, tool connector, and MCP server becomes part of your agent's supply chain. Treat these dependencies with the same rigor you would apply to any third-party software component.
Step 4: Build and iterate
Implement the agent logic, starting with the simplest viable version. Test each component in isolation before combining them. A working single-agent system with two tools teaches you more than a multi-agent architecture that never reaches production.
Step 5: Evaluate and test
Agent evaluation goes beyond unit testing because behavior is non-deterministic. Build evaluation harnesses that test against diverse inputs and edge cases, including adversarial inputs like prompt injection attacks. Track metrics like task completion rate, tool invocation accuracy, and hallucination frequency.
Step 6: Deploy to production
Deploy to cloud infrastructure with appropriate identity bindings, network access controls, and monitoring. Permissions that were convenient during development must be scoped to least privilege. A developer's local agent that used a personal API key now needs a properly scoped service account with audit logging.
Step 7: Monitor and improve
Continuously track tool invocations, data access patterns, error rates, and anomalous behavior. Agents evolve after deployment because their inputs are unpredictable. What the agent does in testing may look very different from what it does when exposed to real user inputs.
Common pitfalls in AI agent development
Most agent development guides focus on getting agents to work. This section covers what goes wrong once they do, drawn from practitioner experience with production AI workloads.
Overprivileged agent identities
Agents are often granted broad IAM permissions during development so they "just work." These permissions persist into production, creating an unnecessarily large blast radius. Scope agent identities to the minimum permissions required for each specific task, and review them with the same rigor you apply to human user accounts.
Untracked agent supply chains
A single agent may depend on multiple models, tool integrations, MCP servers, prompt templates, and data connectors, creating complex AI supply chain security requirements. Without a clear inventory of these components, similar to a software bill of materials, teams cannot assess their exposure when a vulnerability surfaces. This is especially acute with MCP servers, which are often community-maintained.
Ignoring runtime behavior
Static code analysis catches configuration issues, but agents exhibit non-deterministic behavior by design. Prompt injection, unexpected tool invocations, and data exfiltration attempts only manifest through real-world inputs at runtime. Teams that only test agents during development miss an entire class of risks.
Shadow agents and ungoverned deployments
As frameworks lower the barrier to entry, teams across the organization spin up agents without centralized visibility or security review. According to the Wiz State of AI in the Cloud 2025 report, the proliferation of AI services across cloud environments far outpaces most organizations' ability to inventory and secure them.
Exposing sensitive data through RAG and knowledge bases
Agents that use retrieval-augmented generation connect to data stores containing potentially sensitive information. Without proper access controls, agents can inadvertently surface data they should never reach. Imagine a customer-facing agent connected to an internal knowledge base containing both public documentation and internal security procedures. Without proper access boundaries, the agent may surface internal procedures in response to a cleverly crafted user query.
Securing AI agents across the development lifecycle
Security must be embedded across every stage of agent development, not bolted on after deployment. Agents authenticate to multiple services, process user-controlled inputs, and take autonomous actions. This combination demands AI agent security best practices that connect code, cloud, and runtime context.
During development: Scan agent code for hardcoded credentials, insecure tool definitions, and vulnerable dependencies. Analyze agent logic for unsafe patterns like unrestricted tool access or missing input validation before it ships.
At deployment: Assess the agent's cloud infrastructure posture, including identity bindings, network exposure, encryption, and data access. Enforce configuration baselines for AI services and verify that development-time permissions have been scoped to production-appropriate levels.
At runtime: Monitor live agent behavior for prompt injection, unauthorized tool invocations, anomalous data access, and rogue actions that only appear through real-world inputs.
No single-domain tool gives you the full picture. A vulnerability in agent code only matters if the agent is deployed with network exposure and access to sensitive data. A misconfigured identity only matters if the agent is reachable and processing user inputs. The risk lives in the combination, which is why organizations building agents at scale need a way to map the relationships between agent components, cloud resources, identities, and data together.
See for yourself...
Learn what makes Wiz the platform to enable your AI security operation
