What a read-only scan for shadow AI agents found on a live ServiceNow instance

[AlexMcDonald]

Built a read-only scanner for shadow AI on ServiceNow, agents, tools, and credentials that are running but were never inventoried anywhere.

One scan turned up seven agents and eleven credentials, twenty nine findings ranked by severity and confidence. A generative AI service credential had no resolvable owner. Seven of the agents were never registered as agents anywhere the platform would list them, they were scripts and flows quietly calling out to a model.

Detection is rule based, not model judged, so the same instance produces the same findings every run, and every finding is tagged confirmed or needs review rather than a flat yes or no. Verified against a live instance. The writeup documents the bugs I hit building it, including a field mapping defect that meant my highest confidence detection tier hadn't actually worked for most of the build.

Full writeup: https://www.linkedin.com/pulse/you-cant-govern-ai-your-instance-dont-know-its-alex-mcdonald-mllve
Repo, open source: github.com/BrianMcD47/AgentCensus

Curious if this matches what others are finding when they actually go looking.

[Abhishek Pal]

Hi @AlexMcDonald ,

This is a useful approach, and in the Australia release I would position it as complementary to ServiceNow AI Control Tower rather than as a replacement for the OOB governance model.

ServiceNow now has an OOB capability specifically aimed at this problem:

AI Control Tower
-> Enterprise AI Discovery
-> AI Inventory
-> Security & Privacy
-> Governance lifecycle

Enterprise AI Discovery explicitly addresses visibility gaps, including shadow AI, and can discover AI assets such as:

- AI systems
- Agents
- Models
- Prompts
- Tools

across the Now Platform and supported external AI platforms through AI Service Graph Connectors.

What I particularly like about your scanner is that it is looking at a different layer:

Configured AI asset
vs.
Actual implementation evidence inside the instance

For example:

Script Include
-> REST call
-> External LLM

Flow
-> Custom Action
-> Generative AI endpoint

Scheduled Job
-> Integration account
-> AI service

Credential
-> Active
-> No identifiable owner

Those patterns may be worth surfacing even when there is no corresponding governed AI asset.

One terminology point I would consider:

A script or Flow calling an LLM should not automatically be classified as an "AI Agent".

I would classify findings separately as:

1. Registered AI Agent
2. Unregistered AI Agent
3. AI-enabled script/Flow/integration
4. AI model/provider usage
5. AI credential/service account
6. Orphaned AI credential
7. Unregistered MCP/tool integration

That distinction will make the findings more defensible because calling a model does not necessarily imply autonomous/agentic behavior.

For an enterprise implementation, I would correlate your findings against AI Control Tower.

Example:

Scanner discovers outbound AI call
-> Resolve provider/model/credential
-> Search AI Control Tower inventory
-> Matching governed asset found
-> Confirm ownership and controls

-> No matching asset found
-> Flag as potential unmanaged/shadow AI
-> Send for AI steward review
-> Register/manage the asset if confirmed

For credentials, I would also avoid inspecting or exporting secret values.

Only collect metadata such as:

- Credential identifier
- Credential type
- Connection/alias
- Application scope
- Referencing integration
- Service account
- Owner/support group
- Active/inactive state
- Last known usage where available

Then use the result for governance rather than credential extraction.

Another useful comparison would be the AI Control Tower Security & Privacy view.

It can provide information around:

- AI agent access issues
- Dormant AI agents
- Privileged AI agents
- Agent/workflow/tool relationships
- Access mapping

Your scanner could therefore concentrate on finding the things that have not entered that governed inventory yet.

I also like the read-only design.

For discovery/governance tooling, I would keep the scanner:

Read-only
-> Evidence-based
-> Repeatable
-> No secrets collected
-> Confidence scored
-> Clear false-positive explanation
-> Linked to the original ServiceNow record
-> Routed to a human/AI steward for confirmation

I would not automatically disable credentials, scripts, Flows, or integrations based only on static detection.

One other thing I would add to the report is coverage transparency.

Your screenshot already mentions unreadable tables. I would take that further and report:

Scanned:
- Tables
- Script records
- Flow/action records
- REST configurations
- Credentials/connections

Not scanned:
- Restricted tables
- Protected application internals
- External infrastructure
- Runtime-only calls

That prevents "0 findings" from accidentally being interpreted as "0 risk".

For Australia customers, it would be very interesting to run:

AgentCensus
vs.
AI Control Tower Enterprise AI Discovery

on the same instance and categorize the differences into:

- Found by both
- Found only by AI Control Tower
- Found only by static scan
- False positive
- Confirmed shadow AI

That comparison would provide very useful data about where configuration-based discovery and implementation-level scanning complement each other.

Current ServiceNow references:

AI Control Tower:
https://www.servicenow.com/docs/r/intelligent-experiences/ai-control-tower/exploring-ai-control-towe...

Enterprise AI Discovery:
https://www.servicenow.com/docs/r/intelligent-experiences/ai-control-tower/enterprise-ai-discovery.h...

AI Connections:
https://www.servicenow.com/docs/r/intelligent-experiences/ai-control-tower/ai-discovery-setup.html

Security & Privacy / Access Map:
https://www.servicenow.com/docs/r/intelligent-experiences/security-privacy-tab.html

Overall, I think the strongest use case for this type of scanner is identifying potential AI usage that has not yet made it into the organization's governed AI inventory, then handing those findings to AI Control Tower rather than creating a separate governance system.

Hope this helps!

If this response helped, please mark it as Helpful.

Kind Regards,
Abhishek Pal

[AlexMcDonald]

This is excellent feedback, thank you for the depth here. The classification split is the right call, I conflated 'calls a model' with 'is an agent' which I agree is a defensibility problem. Planning to rework the taxonomy along those lines. The AI Control Tower correlation idea is also the better long-term architecture, positioning this as the pre-inventory layer that feeds into governed tooling rather than a competing system. Appreciate you taking the time to write this out.

[Abhishek Pal]

Hi @AlexMcDonald ,

Glad that was useful, and I agree with the direction you’re taking.

Positioning AgentCensus as a pre-inventory discovery layer makes a lot of sense:

Discovery
-> Classification
-> Evidence / confidence
-> Human validation
-> AI Control Tower registration and governance

I also think separating “AI-enabled integration” from an actual “AI Agent” will make the findings much easier to defend during security and governance reviews.

If you later add correlation with AI Control Tower, one useful output could be:

- Discovered and governed
- Discovered but not registered
- Registered but not detected
- Needs review
- Confirmed shadow AI

That would make the tool especially valuable for identifying governance gaps without creating a parallel source of truth.

Really interesting work. Thanks for sharing the implementation details with the Community.

Kind Regards,
Abhishek Pal

[AlexMcDonald]

That five-state breakdown is a good addition, especially 'registered but not detected,' since that's the case that would catch a gap in the scanner itself. I appreciate you working through this with me.