Securing Agents in the Customer's Cloud
Understand how to secure agents operating in a customer's cloud environment by managing user authentication, service identities, and authorization policies. Explore how to enforce credential boundaries, prevent unauthorized access, and verify compliance with regional data hosting requirements. Practice structuring secure access controls and evaluating risk using operation records and cloud IAM roles.
A document assistant can sign in a user successfully and still lack authority to read the requested document. The user’s identity, the application’s cloud identity, and a connected-account grant answer different authority questions. Securing that request means deciding which credential serves each operation and enforcing its boundaries before execution. The result should remain safe even when an authorized document contains instructions to steal another tenant’s data.
Tracing u17’s authority
Start with an authority review of a document assistant. User u17 belongs to tenant north; the online application runs as svc-query; a separate ingestion job runs as svc-ingest. The browser session establishes the external identity, and an application-owned binding associates that validated identity with u17 and north.
Three decisions are distinct:
Authentication: Establishes an identity through a validated authentication mechanism.
Application account binding: Associates the validated external identity with an internal account and tenant.
Authorization: Determines whether that account may perform a particular operation on a particular resource.
A model’s assertion establishes none of these. For a document read, the application must authorize the user/resource combination, and the backend must independently permit the workload’s cloud operation. Successful sign-in proves neither document access nor publication rights.
A workload’s service identity does not automatically represent the signed-in user. User-authorized access and service-account access serve different purposes.
Define the agent’s effective authority as the operations that survive all applicable trusted gates for the selected credential mode. It is not the union of every credential available somewhere in the deployment. For u17, the assistant can read permitted document N7; possession of an ingestion credential elsewhere must contribute nothing to that interactive permission.
Binding ext-42 safely
The server-owned record is:
{"external_subject": "ext-42", "user_id": "u17", "tenant": "north", "linked_account": "link-17"}
The validated subject selects this record. A request naming link-29, a prompt supplying another email, or document text declaring tenant=south cannot replace it. Resolve a connected account from the internal account’s ...