In Part 1 of this series, we walked through how AI agents on ServiceNow actually work: instructions as the program, tools as the hands, and confidence gates deciding when an agent answers and when it hands off. We ended on a warning: capability is the easy half. This post is about the harder half, and it starts with a question anyone responsible for enterprise ServiceNow implementation services will eventually have to answer.

Picture how a normal change reaches a ServiceNow production instance. The update set gets diffed. Someone reviews the code. ACLs get tested in a sub-prod. A CAB meeting happens, someone signs off, and only then does the change go live. It’s slow sometimes, and we all complain about it, but it exists for a reason: production is where the business lives.

Now picture how an AI agent reaches the same instance. Someone writes instructions in plain English in AI Agent Studio. They attach a few tools. They test it in a demo; it looks smart, everyone’s impressed, and it ships.

Nobody diffed the instructions. Nobody computed what those tools can actually touch. Nobody checked the combination against any policy. In most organizations we’ve worked with, there is no gate at all, because the existing gates were built for code and configuration, and an agent is neither.

We’ve been building agentic workflows on the Now Platform for a while now, alongside the more traditional enterprise ServiceNow implementation services work our team has always done, and somewhere along the way our team arrived at an uncomfortable conclusion:

The riskiest moment in an agent’s life is the day it ships.

Runtime problems get noticed eventually. Someone complains, a record looks wrong, a cost report raises eyebrows. But the decisions that determine an agent’s blast radius, what it’s told to do, what it’s allowed to touch, and how far its tools actually reach are all made before the first execution. And in today’s rush to deploy, those decisions are getting made by default rather than by review.

Your change control was built for code. Agents aren’t code.

It took us a little while, and a fair number of client engagements across our ServiceNow consulting services practice,  to articulate why our usual review instincts kept coming up short with agents. It comes down to three things.

1. Instructions are code that nobody reviews.

An agent’s behavior lives mostly in its natural-language instructions. That’s the program, and it deserves the same discipline any other ServiceNow application development artifact would get. And yet in most deployments we’ve seen, those instructions get less scrutiny than a one-line business rule would. Ambiguous directives (“gather all relevant context”), missing boundaries, phrasing that’s wide open to prompt injection from ticket content- these are bugs, but no code review ever sees them because they don’t look like code.

2. Tool grants compose in ways nobody added up.

Each tool looks reasonable on its own. Read incidents. Search the knowledge base. Update a record. But an agent holding ten reasonable tools is not ten reasonable things; it’s one entity that can chain them, in orders nobody predicted, under instructions that shift with every conversation. Reviewing tools one at a time misses the thing that actually matters, which is the combination.

3. The real permission surface is recursive.

This was the one that genuinely surprised us. On ServiceNow, a tool is rarely just a tool. It wraps a flow, which calls a subflow, which invokes a script include, which runs a GlideRecord query that isn’t scoped to any particular table. The agent’s declared access is whatever its tool list says. Its effective access is the transitive closure of everything underneath. Those two numbers are almost never the same, and the gap is where the risk hides.

This picture came out of our lab work, on an agent originally scoped for a fairly standard ServiceNow ITSM implementation services engagement, and it’s the one that changed how we talk about agent risk internally. An incident agent with four innocuous-looking tools, whose dependency chain quietly reached twenty-three tables, including two HR tables nobody had intended, via a shared script include that had been reused for years. Nothing malicious. Just composition nobody had computed.

Four gates before an agent ships

Our answer was to build the review process the platform doesn’t have yet, because rethinking how to implement ServiceNow for enterprise IT agents responsibly meant filling a gap the vendor tooling hadn’t closed yet. The first version actually came out of an internal hackathon; one of our engineers was uneasy about exactly the reach problem above and built a pre-deployment analyzer to prove the point. It worked well enough that we kept developing it in our labs. To be clear, it isn’t a product you can download today; it’s a working prototype, and honestly, the lessons from building it matter more than the tool itself. It inspects an agent the way a careful security reviewer would, and issues a verdict before anything reaches a production instance. Four gates.

Gate 1 — Instruction analysis

Treat the instructions as source code and review them like it. We use an LLM-assisted pass that flags risky directives, ambiguity, missing boundaries, and patterns that make injection easy, the phrases that effectively tell an agent “do whatever the ticket text says.” The findings read like a code review: line-level, specific, fixable. The first time we ran it on our own agents, it flagged wording we’d written ourselves and considered perfectly clear. It wasn’t.

Gate 2 — Tool analysis

For every attached tool: what does it grant, at what scope, with which credentials? The output is a permission inventory for the agent as a whole, which sounds obvious until you realize almost nobody has one for any agent they’ve deployed.

Gate 3 — Recursive reach

The gate that does the real digging. Walk each tool down through its flows, subflows, and script includes, and compute the effective access: every table readable or writable, every integration callable. This is mechanical work a human reviewer would never do by hand for every agent, which is exactly why it wasn’t being done at all.

Gate 4 — The policy gate

Findings only matter if something acts on them. The last gate checks the analysis against a policy registry: organizational rules written as machine-checkable statements. Agents handling incident data may not reach HR tables. Write access requires scoped credentials—no unbounded queries in any dependency. Every deployment then earns one of three verdicts: approve, approve with constraints, or block with the reasons attached, so the conversation with the agent’s builder is about two specific findings rather than a vague sense of risk.

The principle underneath all four gates: govern at design time, verify at runtime. Runtime checks are necessary, but they’re the seatbelt. The pre-deployment gate is the driving test. You want both, and most organizations currently have neither.

The findings that keep repeating

Once we started running agents through the pipeline in our lab, the findings settled into a pattern fast.

Two things stand out to us in that distribution. First, the top categories over-broad tool grants and ambiguous instructions are precisely the things no existing review process even looks at. Second, injection-prone patterns sit at the bottom not because injection isn’t dangerous, but because it’s the one risk people have already heard about. The quieter risks are the ones shipping every day.

And the point of a verdict with constraints is that it’s actionable. Scope the credentials. Bound the queries. Tighten the two ambiguous instruction branches. Re-run the analysis, and the risk picture changes materially.

What we haven’t solved yet

Since this is meant as a working account and not a brochure, here’s where the prototype still falls short. The LLM-assisted instruction review produces false positives; roughly a fifth of its flags are things a human reviewer waves through, and tuning that down without missing real issues is ongoing work. The recursive reach analysis handles flows and script includes well, but dynamic patterns (table names built at runtime, for instance) can only be flagged as “unknown reach,” which is honest but not satisfying. And the hardest problem isn’t technical at all: who owns the gate? Platform team, security, the AI CoE, or the ServiceNow managed services partner running the instance day to day? We’ve seen a different answer at every organization, and until someone owns it, the best analysis in the world is just a report nobody reads.

Three positions we’ll defend

1. Instructions are code. Review them like code.

   The most consequential logic in an agentic workflow is written in English, and “it reads fine” is not a review. Instruction analysis belongs in your deployment pipeline with the same seriousness as a code review versioned, diffed, and gated.

2. Permission must be computed, not declared.

   An agent’s tool list tells you its intentions. Only a recursive walk of the dependencies tells you its reach. If your approval process signs off on the declared list, you’re approving a summary written by the optimistic party.

3. Policy has to live in a registry, not a PDF.

   Every organization has an AI policy document. Almost none can enforce a single sentence of it at deployment time. Until the rules are machine-checkable and wired into a gate, the policy is a hope, not a control.

If you remember five things

• Agents ship through a side door. Change control reviews code and config; an agent is instructions plus tools plus everything underneath, and today nothing reviews that whole.
• Instructions are the program. Ambiguity and missing boundaries in natural language are bugs, they just don’t look like bugs.
• Declared access ≠ effective access. The real permission surface is the transitive closure of every flow and script the tools can reach.
• Every deployment should earn a verdict. Approve, approve with constraints, or block. If nobody can say which one an agent received, it never went through a gate.
• Govern at design time, verify at runtime. The seatbelt matters. The driving test matters more.

Get ahead of the question

The industry conversation about agent risk mostly starts at runtime: watch what agents do, catch problems as they happen. That matters. But by the time an over-permissioned agent is running in production, you’re managing a risk you could have removed. The cheapest place to fix an agent’s blast radius is before its first execution, in a gate that treats instructions as code, computes reach instead of trusting declarations, and turns policy from a document into a check.

Agentic AI on ServiceNow earns enterprise trust in one order: measurable, governable, secure, and the organizations getting this right are treating agent governance as a first-class discipline inside their enterprise ServiceNow implementation services roadmap, not a bolt-on afterthought. This is the governable chapter, and in our experience it’s the one that decides whether the CIO’s next question is “what else can we automate?” or “who approved that agent?”

Better to have a good answer to the second question before anyone has a reason to ask it.

Next in the series: once your agents are gated and shipped, how do you actually know how they’re doing in production, how well they reasoned, whether they’re drifting, what a resolution costs? That’s Part 3.

If your organization is deploying agents on the Now Platform and the pre-deployment gate described here doesn’t yet exist, Crest Data’s engineering team is the kind of ServiceNow implementation partner that has already walked this ground in our labs. Talk to us about what a serious ServiceNow solutions provider engagement looks like for agent governance, and we’ll show you the analyzer, the findings, and the policy patterns we’d wire into your deployment pipeline on day one.

Thought Leader: Dhaval Bhimani