Securing AI agents and connected tools.

An AI application includes prompts, retrieval systems, tools, identity services, logs and external integrations. Each boundary may expose sensitive data or grant unintended authority. Start by mapping which information the system can read, which operations it can perform and which users or services authorize those operations.

Distinguish helpful conversation context from trusted instructions. A document retrieved for summarization should not be allowed to redefine system rules, grant permissions or instruct the assistant to disclose credentials. The application must enforce these boundaries independently of the model’s natural-language behavior.

Prompt injection occurs when attacker-controlled or otherwise untrusted material tries to influence a model’s behavior beyond its intended role. An agent might encounter malicious text inside a web page, issue description, email or retrieved document. Because language models interpret instructions and content through similar interfaces, relying on a warning in the prompt alone is insufficient.

Reduce the impact of hostile instructions by constraining tool access, validating outputs and separating data from authority wherever possible. Test adversarial examples during development and after significant changes to prompts, tools or retrieval sources. Avoid treating any one filtering technique as a complete defense.

A model should not be able to grant itself permissions by writing persuasive text. Each tool must verify the identity and authority of the requesting user or service. Use narrowly scoped credentials, validate resource ownership and reject actions outside the approved workflow. For example, the fact that an agent can read a customer record should not imply it can issue a refund or modify that customer’s account.

Connected-tool protocols can standardize interactions but do not remove the need for authorization. Review the security requirements of the exact protocol version and transport being deployed, and prevent credential leakage through URLs, logs and inappropriate token forwarding.

Requiring approval for every low-risk retrieval would make an assistant unusable. Requiring none for high-impact actions would create avoidable exposure. Design approval around consequences: sending external messages, transferring funds, modifying access permissions and deleting records deserve stricter safeguards than drafting an internal summary.

Approvals should show the proposed action, relevant context and expected effects in language a reviewer can understand. The final operation must still be authorized and validated by the application after approval; a human confirmation is not a substitute for software controls.

Record important tool invocations, denials, approval decisions and errors while applying appropriate limits to sensitive data retention. Look for unusual sequences, repeated denied actions and unexpected access patterns. Establish a mechanism to suspend tools or revoke credentials when suspicious activity is detected.

Security evaluation should include malformed inputs, untrusted retrieval content, conflicting permissions and integration failures. Keep the testing strategy current as the product gains new capabilities. An agent becomes a different security system whenever it receives an additional powerful tool.