A research agent is comparing software vendors when a webpage asks it to upload the company’s internal requirements document to unlock a better comparison. The request sounds helpful. It also asks the agent to share confidential information without the user’s permission.
This is where the engineering behind an agent matters. At PF Labs, we help businesses turn AI agent ideas into practical workflows with clear boundaries around data access, tool use and execution. For teams adopting agents, those decisions shape how confidently they can put the technology to work.
Building safer AI agents means accounting for what happens when an agent encounters misleading instructions or attempts an action beyond its assignment. Accurate answers matter. Keeping sensitive information protected throughout the task matters just as much.
Consider a business asking an agent to compare three vendors against an internal requirements document. Following that assignment from request to report shows how architecture, scoped permissions and evidence checks help keep research useful and controlled.
Start With What the User Actually Authorized
The request seems straightforward: review requirements, research vendors, and produce a comparison.
However, completing it involves several distinct permissions. The agent needs access to the selected document, public vendor information and a place to prepare its report. Contacting sales teams, submitting forms or sharing the document would extend the assignment.
Define those boundaries before execution begins.
A task specification should identify the permitted sources, available tools, expected deliverable and conditions that require clarification. It should also establish a research budget so the agent cannot search indefinitely.
For our vendor comparison, success means delivering a supported assessment. Finding an inaccessible pricing page might justify reporting a limitation. It does not automatically justify creating an account or contacting the vendor.
This definition gives the system a concrete basis for accepting or rejecting proposed actions.
Structure the Deep Research Agent Architecture Around Boundaries
A useful deep research agent architecture separates coordination, information gathering and report preparation.
The coordinator interprets the request and identifies comparison criteria. Research specialists collect evidence for individual vendors. A synthesis stage assembles the findings against the requirements.
Anthropic’s published research architecture uses a lead agent to plan work, delegate research and synthesize results. Its engineering account also discusses the importance of task descriptions and tool design.
For our example, each specialist could receive public comparison criteria without receiving the complete internal document. Sensitive details can remain available only to the component that needs them.
That separation reduces unnecessary exposure. It also makes the workflow easier to inspect: engineers can identify which component accessed a source, produced a finding or requested an operation.
Multiple agents do not automatically create security isolation. Each boundary needs corresponding access controls. Otherwise, separate roles may still share the same broad permissions.
Make the Agent as Tool Interface Explicit
The agent as tool pattern provides a practical way to delegate bounded work.
Instead of transferring the entire assignment to another autonomous agent, the coordinator invokes a specialist through a defined interface. OpenAI’s Agents SDK documents this pattern by exposing agents as callable tools. For example, the coordinator might request:
“Find published evidence about Vendor A’s deployment options and data retention controls.”
The specialist should return structured findings, supporting URLs and unresolved questions. Its interface can require those fields and impose execution limits.
Its permissions should match the assignment. Public research needs browsing access. It generally has no need for email sending or customer database access.
Crucially, a specialist’s output cannot expand authorization. If it recommends uploading the requirements document, the coordinator must treat that recommendation as an untrusted proposal.
Delegation distributes work. The application must continue enforcing the original task boundaries.
Apply Zero Trust for AI Agents at Every Resource Boundary
A connected tool can make an action technically possible without making it appropriate.
Applying zero trust for AI agents means checking the identity, authority and scope behind resource access. Microsoft’s guidance on securing agentic systems recommends isolated agent permissions, narrowly scoped tools and deterministic validation.
In our workflow, the document service should allow access to the selected requirements file. It should reject requests for unrelated documents, even if the model invents a persuasive reason to retrieve them.
The same applies to outbound transfers. A browsing tool’s ability to retrieve public pages should not imply permission to upload internal files.
Enforce these decisions through application services and tool gateways. Credentials should remain outside model context wherever possible, with access limited in scope and duration.
This approach assumes the model can make a mistaken request. The surrounding system decides whether that request is allowed to proceed.
Handle the Malicious Webpage Without Expanding the Task
Now return to the vendor page requesting the confidential document.
The retrieved page contains information relevant to the comparison alongside an instruction that attempts to change the workflow. The agent needs to distinguish source material from authorized direction.
Marking retrieved content as external and untrusted can help establish that distinction. However, instructions alone cannot guarantee correct behavior.
The stronger protection is that the research specialist cannot upload internal files. It lacks both access to the document and an authorized upload operation.
If another component attempts the transfer, the execution layer checks the destination, data and task scope. The request fails because the user never authorized that disclosure.
NVIDIA’s guidance on deploying more secure AI agents emphasizes access controls, sandboxing, restrictions on outbound network connections and secret management as complementary protections.
The workflow can then continue using available evidence or report that some information remains unavailable.
Validate Evidence Before Turning Findings Into Conclusions
Preventing data exposure addresses one failure mode. Research quality introduces another.
Suppose a vendor’s marketing page says its product supports private deployment. A specialist summarizes that as confirmation that the product satisfies every internal hosting requirement. The conclusion exceeds the evidence.
Keep each finding linked to its source and distinguish published statements from verified compatibility. Record missing details explicitly, such as unsupported regions or unclear retention settings.
The synthesis stage should compare evidence against individual requirements rather than treating a confident summary as proof.
For significant claims, reviewers should be able to inspect the supporting passage and understand any qualification.
An additional model can help review findings, but it can repeat the same mistake. Source checks and deterministic validation remain necessary where the underlying facts permit them.
Make Trustworthy Agents in Practice Testable
Trustworthy agents in practice require evaluations that reflect how the workflow can fail.
Test the vendor comparison with a malicious webpage, an unrelated document request, conflicting specifications and an unavailable search tool. Include a specialist that returns an unsupported claim or recommends an unauthorized action.
Assess whether the system completes useful research while maintaining its boundaries.
Relevant measures include unsupported claims, blocked unauthorized actions, information exposed outside the intended scope and successful recovery from tool failures. Record tool requests, authorization outcomes and source references without unnecessarily duplicating confidential content in logs.
Australian cybersecurity guidance on agentic AI harnesses emphasizes controls enforced by the agent’s surrounding software, alongside monitoring and oversight.
The final report should explain findings, evidence and limitations. The operational record should explain how the system reached that result. That combination makes safer AI agents useful: they can investigate independently while their access, actions and failures remain accountable.
Build Safer AI Agents With PF Labs
Planning an AI agent for research or business workflows? PF Labs can help you turn your requirements into a practical development roadmap with safety considered from the start.
Talk to our team about your use case and the architecture, access controls and testing your agent will need. Contact PF Labs to discuss your AI agent project.