Start with what the system can reach
A model that drafts text in a sandbox has a different risk profile from an assistant that reads your file store, calls APIs, or sends messages to customers. The useful starting point is the architecture: the identities, data stores, connectors, and actions involved in answering a request.
The user’s entitlement needs to survive each handoff. If retrieval runs under a shared service identity with broad access, the application must still enforce the user’s narrower permissions. The same question follows the request through every cloud, index, and tool.
Eight areas we examine
- Identity and access
- Role assignments, privileged access, permission boundaries, wildcard grants, legacy authentication, guest accounts, and credential age. Compare what a role permits with what the system needs.
- Cross-cloud trust
- App registrations, federated credentials, consent grants, OIDC providers, assume-role conditions, and external IDs. Identify where an identity changes and what constrains its access after that change.
- Encryption and keys
- Key ownership, key policies and rotation, storage and database encryption, and TLS enforcement. Establish who can use the keys as well as whether encryption is switched on.
- Secrets handling
- Vault and parameter-store use, pipeline credentials, templates, and hardcoded keys. Check which secrets the agent’s role can read and whether they open paths beyond its intended scope.
- Configuration baseline
- Policy assignments, organization controls, native posture services, and resource drift. A documented baseline only helps when the deployed environment still follows it.
- Network and exposure
- Network design, security groups, private and public endpoints, and outbound paths. An assistant’s ability to communicate externally matters alongside its access to private data.
- Data and storage
- Bucket and container policies, workspace permissions, database exposure, backups, and snapshot sharing. Check that retrieval does not quietly discard the permissions of the source records.
- Logging and detection
- Audit and sign-in coverage, retention, flow logs, and model and agent invocation logs. Determine whether the evidence would let your team reconstruct an unexpected action.
Tools produce leads. People confirm findings.
Configuration inventory and automated checks help establish coverage. Depending on the estate, the review may draw on Scout Suite, Prowler, identity and policy analysis with Cloudsplaining, PMapper, ROADrecon or AzureHound, and template or credential review with Checkov and Gitleaks. Native posture reports are inputs to the review as well.
The choice of tool follows the environment and the written scope. Discovery or enumeration capabilities must be distinguished from capabilities that change or exploit an environment. Read access for the architecture review does not authorize broader testing.
An automated result is a candidate finding. We confirm the affected resource, the relevant permission or setting, and the practical impact before reporting it. A benchmark reference provides context, but it cannot replace examining how this system is used.
Bring the cloud review back to the user
An over-broad role, an exposed storage container, or a credential available to a tool can make an otherwise careful entitlement design ineffective. The final check is whether two users with different permissions remain different users from the system’s point of view.
That is why the architecture review and the AI tests belong together. The cloud review establishes the paths that exist. Tests with tiered accounts establish whether the assistant can take those paths on behalf of someone who should not be able to.
