Discovering GCP Vertex AI Agents with ServiceNow AI Control Tower!

marwahajlao · 2 hours ago

How I found an AI agent hiding in Google Cloud?

Before you start: Complete the prerequisite setup for the Service Graph Connector for GCP Vertex AI first: create the GCP service account, configure the required IAM roles, and generate the JKS file. Part of these steps are covered in part 1 : https://support.servicenow.com/kb?sys_kb_id=a422959647ea3a90c2488d01426d43b2&id=kb_article_view. This article starts from a working connection and focuses on discovery.

Let's find an AI agent

Last week I deployed a new AI agent on Google Cloud and I wanted to discover it from my ServiceNow instance. It is called “image-scoring-9674” and it is designed to analyse an image and assign a score based on predefined criteria.

In this article we're going to find it from ServiceNow. We'll connect AI Control Tower to GCP Vertex AI, run the AI discovery, follow the data as it moves through the import set and the transform maps, and watch the agent turn up in the AI inventory as an asset someone can actually govern by the AI steward and the compliance & governance team, for sure.

Screenshot 2026-09-17 at 10.32.13.png

Worth pausing here, you may notice My project holds three agents and only one of them is in us-central1. The other two live in us-west1, so this connection will never look at them. There is no error and no warning for that — they are simply out of scope. One connection per region, or two thirds of the estate stays invisible.

Step 1 : The connection

Head to AI Control Tower > Configurations > AI connections. This is where you register the third-party systems you want AI Control Tower to look inside.

Once you choose what type of connection, the system asks you to upload the Java Keystore (JKS) certificate generated in Part 1.

Once you upload the JKS certificate, an X.509 certificate is created and now you can create and test the connection.

When all the information is provided then you can see both integrations showing up for GCP Vertex AI, both daily, both Success. One does the inventory (Discovery), one collects invocations and traces (Execution). Open the connection itself and two fields deserve your attention.

I decided to use the region “us-central1”, because that is the region I usually work in. That is a choice, not a constraint, set whichever region matches your project.

One tip: click Update and test connection after any key rotation. It re-validates the JKS against Google.

Step 2 : What the connector brings with it

Before running anything, have a look at what the application installed. Seven data sources, one per entity type, Discovery, Model, System, Prompt, Tool, SystemSubcomponent and Execution, all of type Custom (Load by Script).

No file drop, no FTP: each one runs script logic that calls the Google APIs and stages the response. And look at that naming: agents, the models they call, the prompts they use, the tools they invoke, the sub-agent links. The AI landscape, decomposed into objects you can govern separately.

The import schedules are where it gets clever.

Two schedules run daily on their own: Discovery and Execution. The other five, Model, System, Prompt, Tool and SystemSubcomponentM2M, have Discovery as their Parent and run After Parent Runs. So Discovery is not one job among seven, it is the orchestrator: it fetches once, then its children process what it staged, in order, with nothing extra for you to schedule.

One setting worth knowing: Concurrent Import with a partition size of 1,000. With three agents you will never notice it. With a few thousand deployed agents it is the difference between a job that finishes and a job that does not.

Step 3 : Execute now

No need to wait for the schedule to run. Click Execute now and you get exactly this much encouragement:

Everything useful is downstream, so let's follow it.

Step 4 : Following the run

Open the execution record and from there you can start getting relevant information. You can easily identify the import set that was used and the execution context.

The Execution is the run wrapper. The Execution Context is the useful field here, it is what tells you whether the System job ran off this Discovery pull or yesterday's.

From the import set, note the staging table (SG-GCP AI Asset) and the related lists along the top, especially Outbound Http log, which is the best tab in the whole connector.

Three GET calls, all 200, done in few seconds. Each one maps straight back to the IAM work from Part 1. You can see from here what API calls were invoked and what they look for.

Call	API	Role it needs
Enumerate the project	Cloud Resource Manager	roles/browser
Fetch agents from Vertex AI	Vertex AI (regional endpoint)	roles/aiplatform.user
Fetch invocation traces	Cloud Trace	roles/cloudtrace.user

Which is why this is your first stop when things go wrong: a 403 here names the missing role and the API it belongs to.

Now open the Import Set tab and open the ISET record.

One row, State Inserted, no error. But the target record here is SG-GCP AI System, another staging table, not an asset table. That’s the fan-out: Discovery retrieves cloud data from Google and the integration routes the data into the appropriate staging tables, where transformation logic maps each entity to its corresponding destination.

Filter Table Transform Maps on the sn_ai_disc_gcp_sgc_sg_gcp_ai_system source table and there it is: SG-GCPVertexAI-System, writing into AI System Digital Asset (alm_ai_system_digital_asset).

Finally, we can know where the discovered GCP Agent is going to be stored. We have the answer : alm_ai_system_digital_asset, but not only there also visible in the AI Control tower.

Step 5 And there it is

Now go to AI Control Tower > AI assets > AI asset inventory - Unmanaged > AI systems.

Third row: labinstance001 image-scoring-9674, vendor Google, state Deployed, lifecycle status AI steward review. We found our hidden Google agent. Nobody filled in a form for mine, it appeared because the connector went looking, timestamped to the same second as the import. Notice it appears in the “unmanaged” AI asset inventory section.

So here we can say that Discovery did not govern my agent. It made it visible, put it in a queue, and handed it to a human.

Questions to Consider :

How can I link my AI asset to the CMDB?

“ServiceNow has introduced the cmdb_rel_asset_ci table, a many-to-many (M2M) relationship table that formally links an Asset record (e.g. alm_ai_system_digital_asset) to its corresponding CMDB CI record (e.g. cmdb_ci_function_ai or cmdb_ci_ai_model_deployment).

It is the standardized, future-proof way to express the Asset↔CI relationship in AICT — replacing the older approach of storing a direct reference field on the CI table.

Consider it as cmdb_rel_ci, but with an Asset-to-CI linkage and a relationship type”. Please refer to this article for further information

What is the difference between Managed vs Unmanaged

This is more than a label. Only Managed assets trigger governance workflows, risk assessments, value measurement, and monitoring. AI Stewards are the only users who can move assets between Managed and Unmanaged states. Product Owners see only Managed assets, keeping their view focused instead of cluttered with everything discovery finds.

This is the smart part of the design: seeing something does not mean you must manage it. Discovery can show the full AI landscape, including things you did not expect to find. But the governance team does not have to work on every item right away. Discovery makes the assets visible, the AI Steward decides which ones need active governance.

Conclusion

In the end, the useful part of AI Discovery is not only that it found my Vertex AI agent. It also showed the full path the asset followed: from the GCP connection, through the API calls, into the import set, through the transform map, and finally into the AI asset inventory. That path matters, because it makes the discovery easy to check, explain, and troubleshoot.

The biggest lesson is simple: discovery gives you visibility, but it does not automatically mean everything must be governed at once. It brings hidden AI assets into view, adds them to the right inventory, and gives the AI Steward a clear starting point. From there, the organization can decide what needs active governance, risk review, value measurement, and monitoring.

For me, that is what makes AI Control Tower practical. It does not just say that an AI estate should be governed. It helps you find what is already running, understand where it came from, and choose what deserves attention next. The hidden agent is no longer hidden, and the next step is no longer guesswork.

Final takeaway

The discovered GCP Vertex AI agent is stored in alm_ai_system_digital_asset and appears in AI Control Tower > AI assets > AI asset inventory - Unmanaged > AI systems. To understand how it gets there, follow the article path through the connection, import set, staging table, transform map, and target table. The JKS file setup is the tricky part, so complete those steps carefully before running discovery.