Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Secure a multi-agent AI system by enforcing identity, permissions, isolation, and approval in the software that executes actions—not by trusting the model to follow instructions. Map every path through which agents receive content, access data, call tools, retain memory, delegate work, and affect external systems. Then restrict each path, independently check proposed actions, and test the controls whenever the system changes.
1. Map the system and its trust boundaries
Start with an inventory of the whole workflow, not just the agents’ prompts. A chain can cross models, tools, retrieval services, memory stores, external APIs, and other agents; a failure at one point can propagate to the rest.
- For each agent, record its purpose, owner, model or provider, available tools, data sources, memory, credentials, and downstream agents.
- Draw the trust boundaries between people and agents, agents and tools, agents and other agents, and trusted instructions and untrusted content.
- For every tool, document what it can do, which resources it can reach, whether it can change state, whether its effects are reversible, and how you can observe or verify the result.
- Trace plausible abuse paths: prompt or goal hijacking, tool misuse, privilege abuse, exposed credentials, memory poisoning, compromised integrations, unexpected code execution, data exfiltration, runaway loops or costs, and cascading failures.
NIST’s tool-use work describes useful assessment dimensions such as functionality, access patterns, risk, reliability, modality, and monitoring. Its taxonomy is a way to structure assessment, not a universal risk score: actual risk depends on the tool’s implementation and deployment conditions. NIST’s article, “Lessons Learned from the Consortium: Tool Use in Agent Systems,” was published August 5, 2025, and updated August 7, 2025. It reports that approximately 140 experts attended a January 2025 workshop hosted by CAISI and NIST with the Artificial Intelligence Safety Institute Consortium; that attendance figure is workshop context, not a survey result or measure of consensus.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →2. Give each agent only the authority it needs
Make permission a decision enforced by code outside the model. A prompt can describe allowed behavior, but it cannot reliably authorize or constrain a tool call. Put the final check in an execution component, gateway, or policy service that evaluates the caller, target resource, operation, and request.
#1 Best Overall
- Start with deny-by-default access; explicitly allow the tools and operations required for the task.
- Scope access by agent, task, resource, operation, and environment. Separate read-only identities from identities that can write.
- Check authorization for the exact proposed operation immediately before execution. Do not rely on a model response, agent identity, valid signature, or generic approval indicator as permission by itself.
- Keep the model’s decision to propose an action separate from the service that carries it out. The service should independently validate authority and policy.
- Vet integrations and data sources. Review and pin dependencies where appropriate; tool descriptions and outputs are inputs, not trusted policy. OWASP’s MCP Top 10 project identifies tool poisoning and software supply-chain attacks among its risk categories. The project describes itself as a beta and a living document, so treat it as evolving guidance rather than a settled standard.
3. Establish agent identities and protect credentials
Give each agent a distinct identity, such as a dedicated service account or bot identity, so actions can be attributed and access can be revoked without disabling unrelated workflows.
- Issue short-lived credentials scoped to the current task and required resources.
- Keep long-lived production secrets out of prompts, configuration files, and agent environments; separate administrative identities from agents and avoid standing administrative roles.
- Prevent credentials and sensitive information from leaking into logs, traces, memory, and tool outputs. Redact secrets and sensitive personal or confidential data while retaining enough structured metadata to investigate important actions.
- Record which agent identity made a request, which policy was evaluated, what was allowed or denied, and what the tool reported doing.
The OWASP DevSecOps Guideline, in its “AI Agent and MCP Security” threat-model section, puts the risk succinctly: “An agent combines three things that are dangerous together: access to private data, exposure to untrusted content, and the ability to act or communicate externally.” A useful security review therefore considers those capabilities together, rather than examining prompts or credentials in isolation.
4. Isolate execution, memory, and untrusted content
Constrain what an agent can reach even if its instructions are overridden. Run it in a sandbox or similarly restricted environment, and limit filesystem access and network egress to what its task actually needs.
- Separate agents’ and users’ sessions, memory, and context so one workflow cannot silently influence another.
- Treat retrieved documents, websites, email, API responses, tool outputs, and conversation history as untrusted. Delimit and label that content, but do not mistake labels for an enforced security boundary.
- Validate structured outputs and tool parameters against schemas and policy before execution.
- For risky documents, one possible defense pattern is to have a quarantined parser with no tool access extract or summarize content, then independently validate any action proposed from it. This adds separation; it does not guarantee that prompt injection has been prevented.
Prompt-injection defenses should be layered. Screening content may help, but do not depend on a filter, a model’s confidence, or instructions to ignore malicious text as the sole control. The decisive protection is to ensure that untrusted content cannot grant the agent new authority and that proposed actions are checked before they take effect.
Rank #3
5. Match safeguards to the consequences of an action
Classify each tool operation by impact, reversibility, statefulness, exposure, and observability. A read-only lookup with a verifiable result is not equivalent to a bulk deletion, payment, privilege change, production deployment, or external message.
| Action profile | What to check | Practical control |
|---|---|---|
| Read-only, limited scope, and readily observable | Whether the identity may access the specific data and whether the result is appropriately protected. | Use a read-only identity, narrow resource scope, and suitable logging. |
| Constrained write with limited, reversible effects | The exact target, permitted fields or operations, and whether the result can be verified or undone. | Validate parameters against a schema and policy; restrict the write surface and record the outcome. |
| High-impact, externally visible, difficult to reverse, or stateful | Caller authority, target, normalized parameters, impact, approval, and whether the request is fresh. | Require human review or independent policy validation; bind approval to the exact action and use replay protection. |
| Weakly observable or poorly bounded | Whether the system can determine what the tool actually did and reconstruct the event. | Improve observability or deny the operation until the result can be monitored and audited adequately. |
For reviewed actions, bind approval to the actor, tool, target resource, normalized parameters, timestamp, and expiry. Require new approval if the target or parameters change. Use short-lived authorization artifacts, replay protection, and idempotency where possible. Fail closed if policy, approval, risk classification, or audit checks fail. Allow review bypass only for actions explicitly classified as low risk.
6. Control agent-to-agent delegation
A receiving agent should treat a delegated request as a request—not as inherited authority. Define which agents may communicate, which message types they may send, and what the receiver is allowed to do in response.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors- Authenticate the sender, then check its permission at the receiving service for the specific requested operation.
- Validate message types and parameters, and prevent chains from escalating privilege or carrying untrusted instructions across trust boundaries.
- If messages are signed, use a maintained protocol implementation and include the sender, intended recipient, message type, payload, creation and expiry times, and a unique message identifier. Reject expired or replayed messages.
- Set limits on chain depth, retries, tokens, and costs. Use circuit breakers to stop cascading failures and runaway loops.
7. Test and monitor the workflow as it changes
Run structured security tests before production and after material changes to prompts, tools, memory, retrieval, policies, or model providers. Keep repeatable cases for:
Best Value
- Prompt override and instructions hidden in retrieved content.
- Unauthorized tool use and privilege escalation.
- Memory poisoning and cross-user or cross-agent influence.
- Data exfiltration and unexpected access to secrets.
- Recursive tool abuse, runaway chains, and circuit-breaker behavior.
- Approval bypass, replayed requests, and changes to an approved target or parameter.
- Trust-boundary failures in agent-to-agent delegation.
Monitor actions and high-risk decisions. Retain versioned evidence of the model or provider tested, tool policy, retrieval configuration, abuse cases, denials, approvals, timeouts, and circuit-breaker outcomes. CISA’s May 1, 2026 announcement, “CISA and Partners Release Guidance on Adopting Agentic AI Services,” summarizes joint recommendations that include threat modeling, continuous monitoring, and regular security assessments. Because that item is an announcement summarizing guidance, those are the recommendations attributable to it here.
Use the results to update the threat model and repeat the affected tests after a meaningful system change. Review evolving agent and MCP security guidance periodically; OWASP labels its MCP Top 10 a beta, living project, not a static checklist.
Architecture choices that change the risk
Compare the actual capabilities and boundaries of each design choice. A generic “safe agent” label does not describe its permissions, exposure, or ability to cause lasting effects.
| Choice | Security question | Risk implication |
|---|---|---|
| Read-only vs. constrained write vs. broad write access | What state can the tool change, and what is the maximum blast radius? | Write authority increases the possible impact; narrow operations and targets to the task. |
| Trusted vs. untrusted input environment | Can the agent read attacker-controlled content while it holds useful authority? | Exposure to untrusted content matters most when paired with data access or the ability to act. |
| Reversible vs. irreversible; stateless vs. stateful actions | What persists, compounds, or cannot be undone if an action is wrong? | Persistent or hard-to-reverse effects warrant stronger validation and approval. |
| Observable vs. weakly observable tools | Can the team verify what happened and reconstruct it later? | Weak observability makes detection, audit, and recovery harder. |
| Isolated vs. shared memory and context | Can one agent, user, or untrusted document influence another workflow? | Shared context can cross trust boundaries unless access and provenance are controlled. |
| Independent execution policy vs. model-directed authorization | Does code outside the model make the final permission decision? | Only an independent enforcement point can reliably reject an otherwise persuasive but unauthorized proposal. |
The right controls depend on the tools’ capabilities, deployment environment, data sensitivity, and consequences of action. This checklist helps structure those decisions; it cannot guarantee that a multi-agent system is secure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
