Anomity Integrates with Google Cloud Vertex AI

Anomity now integrates with Google Cloud Vertex AI. Connect a Google Cloud project and Anomity inventories the AI your company runs there: Vertex AI endpoints and the models deployed on them, tuned models, Agent Engine agents, RAG Engine knowledge bases and the data sources they draw on, Vector Search indexes, and Gemini Enterprise apps and agents. Each one is evaluated against the same cloud AI posture policy that already covers Amazon Bedrock and Azure AI Foundry. The integration is available today from Settings, under Integrations, in the Anomity console, and it holds no Google credential of yours.

This post covers what the connector reads, what it flags, how the keyless setup works, and three findings we chose not to raise because they would have told you something untrue.

Why Vertex AI, and why now

None of the AI running in a Google Cloud project ever touches a managed laptop. Anomity's Endpoint Sensor sees the developer's CLI and the API key sitting in a dotfile, but it cannot see the endpoint that serves the model, the Agent Engine agent running server-side, or the knowledge base someone built over an HR folder. Until now that left the Google Cloud section of the inventory empty, and an empty section reads like a clean one.

Vertex AI is the third cloud AI platform in Anomity's cloud discovery, after Amazon Bedrock and Azure AI Foundry. A company that runs models in more than one of them should not have to write 'require prompt logging' three times. So Vertex AI does not get a policy of its own: it maps onto the same governance questions, answered by one policy, with Google's own word for each control.

It is also a different question from the one our Google Workspace connector answers. Workspace discovery asks which AI apps employees granted OAuth access to their mail and Drive. This connector asks what AI the company itself is running in its own cloud projects, and whether it is governed.

What the connector reads

Vertex AI is regional and has no 'list my locations' call, so the connector sweeps your projects across the locations you pick when you connect. You can also give it an explicit list of projects, which scopes Anomity to exactly the projects you want read.

What it flags

Findings come from Anomity's cloud AI posture policy type, with a template for Google Vertex AI. Each check can be switched on or off per policy, and each finding names the project and location it belongs to.

• Prompt and response logging off. An endpoint with request-response logging disabled has no record of what was sent to the model or what came back.
• No guardrail. No Model Armor template is defined for the project, so nothing filters prompts or responses.
• Guardrail not enforced. Templates exist, but no floor setting enforces one project-wide, so applying it is left to whoever writes the calling code.
• Requests can leave the region. An endpoint in the global location can be served from another region, so inference data may leave the one you chose.
• API key access. An API key can call Vertex AI without an IAM identity, which puts the caller outside every IAM condition, VPC Service Controls perimeter and organization policy that governs identity-based access. On by default.
• Public endpoint. An endpoint with no VPC network attached is served on the public address. Off by default, because many legitimate services are public by design. It is a network attachment check, not a VPC Service Controls perimeter reading.
• Region not allowed and data source not allowed. Optional lists: flag resources outside your approved regions, or knowledge bases that draw on a store your policy does not permit as a model corpus, such as SharePoint or Jira.
• Discovery gap. A project Anomity should have been able to read but could not.

The API key check is new with this connector. Azure has an equivalent finding, but its wording names Entra and Conditional Access, two products a Google Cloud customer may not run, so Vertex AI gets a sentence of its own. If you need a refresher on why a model API key is worth this attention, see our write-up on LLMjacking and stolen-key cost abuse.

Three things it deliberately does not claim

Each of these would have been an easy finding to ship, and each would have been a finding the customer could not act on.

1. Audit logs are not prompt logs. Vertex AI request-response logging records the actual prompt and response. Cloud Audit Logs Data Access records only metadata: who called which model, and when. Only the first missing raises the logging finding, whose sentence says no prompt is recorded anywhere. The audit log state is a note on the project row, so it is still visible. We wrote about why those two records answer different questions in our guide to AI agent audit trails.
2. Model Armor is regional. Inline Model Armor integration with Vertex AI is offered only in some locations; when the connector shipped, those were us-central1, us-east4, us-west1 and europe-west4. Outside them, guardrail posture is reported as not applicable instead of 'no guardrail', because reporting an unavailable control as a disabled one is a finding with no remedy. The supported locations are marked in the picker.
3. No per-agent guardrail check. A Bedrock agent carries its own guardrail setting, so Anomity can say a specific Bedrock agent runs unguarded. Agent Engine exposes no equivalent field, and inferring one from the project setting would be a claim we cannot evidence, so the check is simply absent for Google Cloud.

The same rule applies to permissions. If the Model Armor floor setting cannot be read, usually because the floor settings viewer role was not granted, the project says 'not checked' and names the missing role. It never reads as 'no floor setting enforced' on a project that may well have one.

How it authenticates: no key, anywhere

We could have asked for a service account JSON key. We did not, for a simple reason: Anomity's own cloud AI posture policy flags long-lived static credentials, and asking a customer for exactly the artifact we flag would not survive their security review. The Bedrock and Azure connectors are secret-less too, and Vertex AI should not be the exception.

1. In Anomity, add a Google Cloud connector. Enter your project number, pick the locations to scan, and optionally list the projects Anomity may read.
2. Anomity generates the gcloud commands with every identifier already filled in, built from the same list of roles the connector card shows you. An Open Cloud Shell button sits next to them, so there is nothing to install on your own machine.
3. Run them. They create a workload identity pool and provider in your project that trust exactly one identity, Anomity's, and bind Google's predefined read-only roles to it.
4. Test, then sync. At sync time Anomity exchanges its own cloud identity for a short-lived Google token. Nothing of yours is stored.

Two details make this safe for a multi-tenant service. The pool and provider IDs are minted by Anomity, never chosen by the caller, because every customer's pool trusts the same Anomity identity and a caller-chosen ID would let one tenant point a connector at another's project. And the provider carries an attribute condition pinned to Anomity's own cloud account, so a pool ID on its own is useless to anyone else.

Revoking access is deleting the pool in your own project. Note that deleting the connector in Anomity does not reach into your project to remove the pool for you; the confirmation dialog says so, and names what is left behind.

How Anomity and Vertex AI fit together

Google owns the controls: IAM decides who may call a model, Model Armor filters what goes in and out, request-response logging keeps the record, and VPC networking decides where traffic flows. Anomity does not replace any of them. It reads whether they are switched on, across every project and location you connect, and puts the answer next to Bedrock, Azure AI Foundry, Cloudflare and the AI vendor organizations you connect, such as the OpenAI Platform and the Anthropic Console. A knowledge base that draws on SharePoint is the same question in every cloud, and our guide to auditing the data sources AI agents access explains why it is the one to ask first.

Cloud discovery is one of three collectors. The Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes on each managed device, the Browser Sensor covers AI web services and the accounts used in them, and on agents that expose a hook Anomity decides allow, deny or log before a tool call runs. Findings from Vertex AI route like every other Anomity finding, to the SIEM, Slack or a Jira ticket. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see it against your own Google Cloud projects, book a 30-minute demo.