Coverage
Cloud AI
Find the models your cloud accounts are already running
AI posture in the cloud is an inventory problem before it is a policy problem. Endpoints get provisioned for a demo, wired to a knowledge base, given a wildcard IAM role, and then forgotten. SAF3AI reads Bedrock, Vertex AI and Azure OpenAI read-only and gives you the register you never had.
What you see
The telemetry we pull
Model and endpoint inventory
Every Bedrock model, Vertex AI endpoint and Azure OpenAI deployment your accounts have provisioned — including the ones spun up for a proof of concept and never turned off.
Agents and knowledge bases
Bedrock Agents, Vertex agents and the knowledge bases behind them, with the datastores each one is grounded in.
Principals and permissions
The IAM roles, service accounts and managed identities that can invoke models — the non-human identities your joiner-mover-leaver process never covered.
Cloud audit trails
AWS CloudTrail, Azure Activity and GCP Audit logs, filtered to the AI control plane so model provisioning and invocation are legible without drowning in general cloud noise.
Invocation telemetry
Which principal called which model, from where, how often and at what token volume — the baseline behavioural detection scores against.
Cost by account and workload
Model spend attributed to accounts, projects and teams, so a runaway agent is a budget alert rather than a quarterly surprise.
How it connects
From zero to first signal
- 1
Connect each cloud read-only
A guided wizard generates the exact CloudFormation, Terraform or gcloud script for a read-only role. Nothing SAF3AI provisions can write to your account.
- 2
Scope to the AI control plane
The connector reads the model, agent and knowledge-base surfaces plus the audit events that touch them, rather than ingesting your entire cloud log volume.
- 3
Optionally add object storage
Point the connector at a bucket where you already export logs and it will read them from there, if your organisation prefers export over direct API access.
- 4
Inventory, then baseline
The first pass builds the AI-BOM for each account. Behavioural baselines accumulate from there, so anomaly detection has something real to compare against.
- 5
Cloud entities join the graph
Models, agents, knowledge bases, buckets and IAM principals become graph entities — which is how an over-permissioned role reaching a sensitive datastore shows up as one path.
Read-only by design: the connector provisions no write permissions in your cloud accounts. Enforcement, where you want it, happens at the AI Gateway or through your existing cloud guardrails.
What it catches
Risks specific to this surface
Shadow model deployments
A Bedrock or Vertex endpoint provisioned for an experiment, still running, still billing, still reachable — and on nobody's asset register.
Over-permissioned invocation roles
A service account that can invoke any model and read any bucket because scoping it properly was harder than the wildcard.
Knowledge bases grounded in sensitive data
A RAG datastore built from an export nobody classified, now answering questions for anyone who can reach the agent.
Cross-account and cross-region drift
AI resources appearing in accounts and regions outside your approved footprint, which is a data-residency problem before it is a security one.
Unbounded agent spend
A looping agent burning tokens across a weekend. Anomaly detection on the invocation curve catches it while it is still cheap.
Public or broadly-shared endpoints
A model endpoint reachable from outside the VPC because a security group was widened during debugging and never narrowed.
See Cloud AI in your own tenant
Connect this surface in a pilot and get a mapped inventory, a scored risk list and the attack paths that actually reach your data.