Security, Data and Access

An agent combines the risks of a user, an application and an automated decision service. Security design must reflect all three.

Give agents identities

Each operational agent and execution context should have a distinct identity. Shared technical users obscure accountability and make permissions difficult to revoke.

Human identity and agent identity should remain linked in delegated actions: who initiated the request, which agent acted and under which approved policy?

Enforce least privilege

Access should be limited by task, environment, data domain, organizational scope, action and time. Read access does not imply permission to use data for every purpose, and permission to prepare does not imply permission to execute.

High-risk tools should apply independent policy checks rather than relying solely on the model to respect a written instruction.

Protect transformation data

Project repositories can contain personal information, commercial terms, security designs, production extracts and regulated data. Classification, residency, retention and masking rules apply to prompts, retrieval, logs and evaluation data.

Model and service providers must be assessed for how data is processed, retained and used.

Defend the tool boundary

Retrieved content may contain malicious or misleading instructions. Tool parameters need validation, destinations should be allow-listed where appropriate, and side effects must be logged.

For consequential actions, deterministic controls and approval services should sit between the agent and the target system.

Plan for credential and model compromise

Secrets should not be embedded in prompts or content. Use managed identities or vault-backed credentials, rotate them and monitor anomalous behavior. The operating team needs a rapid way to revoke access, stop workflows and determine what was affected.