technology
How AI Agents Use Tools, Data, and Web Access
An architecture level explainer of how agents select tools, retrieve data, search the web, handle results, and operate within security boundaries.
Published ; updated

A language model can interpret a request and generate a response, but it does not automatically possess current web knowledge, private company data, or permission to change another system. An agent gains those capabilities through tools: controlled interfaces for retrieving information, performing computation, or requesting an action. The important word is controlled. A tool does not make the model inherently accurate or authorized. It creates a path between probabilistic model decisions and external systems. The application around the model must decide which tools exist, whose credentials apply, what inputs are valid, which results return to the model, and when a person must approve the next step. The agent loop connects reasoning to execution A typical run starts with a goal, instructions, and a set of available tool definitions. Each definition usually contains a name, a description, and an input schema. Based on the conversation and current state, the model either answers directly or proposes a tool call with arguments. The host application validates and executes that call, then returns the result as new context. The model inspects the result and chooses whether to call another tool, ask for clarification, request approval, or stop. This is a feedback loop, not direct access from the model to every connected system. OpenAI's tools documentation describes built in tools, function calling, tool search, and remote Model Context Protocol MCP servers as ways to extend a model with web search, file retrieval, custom code, and third party services. The host remains responsible for ordinary software controls. It should authenticate the user, authorize each operation, validate structured arguments, enforce rate and spending limits, set timeouts, and log outcomes. The model may recommend a call, but the service must decide whether that call is allowed. Tools expose bounded capabilities A data tool reads context: search approved documents, retrieve a customer record, list inventory, or query a metric. An action tool changes state: create a ticket, update a record, send a message, or start a job. A computation tool may run code, transform a file, or apply a deterministic formula. Some tools combine categories, which is a reason to split them into narrower operations. Good definitions make the boundary clear. get order status is easier to govern than manage orders . A schema can require an order identifier and reject additional properties. The service can check that the authenticated user may view that order. Separate draft refund from issue refund so review can occur between preparation and commitment. MCP standardizes how clients discover and call externally provided tools. Its tools specification includes names, descriptions, input schemas, optional output schemas, and results that may be structured or unstructured. The specification also warns clients to treat tool annotations as untrusted unless they come from trusted servers. Protocol compatibility therefore does not establish that a server, description, or result is safe. Data grounding supplies context, not truth Grounding means retrieving information relevant to the current task and placing it in the model's working context. The source might be an indexed file collection, a database query, an application API, or a search result. This can make answers more current and specific than relying on the model alone, but retrieval quality sets an upper bound on the result. Three distinctions matter. Access determines which sources the system may reach. Retrieval determines which records or passages it selects. Use determines how the model interprets those items. A permission error, stale index, ambiguous identifier, missing record, or misleading document can affect a grounded answer even when the model follows its instructions. Keep source identity, timestamps, record IDs, and permission context with retrieved material where possible. Limit retrieval by tenant and user before results enter the model context. Do not retrieve an entire sensitive record when a validated field or summary is sufficient. A model context window is not a substitute for a governed data layer, and generated notes should not silently become authoritative records. Web access is a special kind of retrieval Web search can help an agent find current public information, discover source pages, and compare evidence. It should not be described as unrestricted knowledge or guaranteed browsing of every page. Search coverage, page accessibility, ranking, freshness, geography, and tool configuration affect what the agent sees. Websites can be wrong, outdated, spoofed, or contradictory. A robust research workflow records the linked source, distinguishes publication date from access date, prefers primary evidence for consequential claims, and seeks corroboration when sources conflict. The agent should report uncertainty or stop when required evidence is unavailable. For sensitive actions, web content should inform a proposal rather than directly trigger execution. Allowlisting domains can reduce exposure but cannot prove that every page on an allowed site is benign or correct. Likewise, citations improve inspectability but do not validate the cited claim by themselves. Verification remains a separate step. Prompt injection crosses the data command boundary An indirect prompt injection hides instructions inside content the agent retrieves, such as a webpage, email, document, issue, or tool result. The text may tell the model to ignore its task, reveal data, call another tool, or send information elsewhere. Because the model processes instructions and evidence in the same context, it can mistake hostile data for a command. OpenAI's agent safety guidance identifies prompt injection and private data leakage as important risks and states that agents can still make mistakes or be tricked even with mitigations. The danger grows when one workflow combines untrusted reading with privileged writing. For example, a web page should never gain authority to decide where private records are sent. Reduce exposure with least privilege tools, isolated read and write stages, structured outputs between stages, argument validation, domain and content restrictions, tool approvals, and independent authorization at execution time. Treat all external text and tool output as untrusted data. Do not place untrusted content into higher priority instructions. No prompt, detector, or guardrail makes prompt injection impossible, so high consequence workflows need containment and meaningful human control. Reliability lives around the model Tool failures are normal engineering events. APIs time out, credentials expire, schemas change, search returns nothing, and a successful response may arrive after the caller has already retried. Design idempotency keys for state changing calls, bounded retries with backoff, clear timeouts, duplicate detection, and rollback or compensating actions where feasible. Logs should connect the user request, retrieved sources, model selected call, validated arguments, authorization decision, approval, tool result, and final output without unnecessarily recording secrets or personal data. Evaluations should include permission failures, malformed results, stale data, conflicting sources, injection attempts, and interrupted runs, not only the happy path. MCP's security guidance documents risks beyond model behavior, including confused deputy problems, token passthrough, server side request forgery, state handle hijacking, and compromised local servers. Agent security therefore includes identity, OAuth, network boundaries, sandboxing, secret handling, and incident response as well as model guardrails. An agent works because a model can choose among narrowly exposed capabilities and adapt to their results. It works reliably only when the surrounding system constrains access, validates every boundary, preserves evidence, and stops safely when data or tools cannot be trusted. Sources Using tools https://developers.openai.com/api/docs/guides/tools Safety in building agents https://developers.openai.com/api/docs/guides/agent builder safety Tools Model Context Protocol https://modelcontextprotocol.io/specification/2025 11 25/server/tools MCP Security Best Practices https://modelcontextprotocol.io/docs/2026 07 28/tutorials/security/security best practices Cover image credit Cover image by APaskulin WMF , made available under CC BY SA 4.0 . WIKIVISE cropped and converted the source image.
Evidence and review
Sources
- Using tools, OpenAI
- Safety in building agents, OpenAI
- Tools - Model Context Protocol, Model Context Protocol
- MCP Security Best Practices, Model Context Protocol