AI Governance

Overview

AI Governance measures how much autonomy and blast radius an AI agent has been given. It doesn't ask whether an AI call works correctly — that's a data-flow or reliability question. It asks: how much has this agent been trusted to do on its own, and what's the actual worst case if it does the wrong thing?

How this affects your score

AI Governance is weighted 0.15. Its most severe finding — write-capable agent tools — is high to critical severity on its own, and it's the precondition for most other findings in this category: an agent with no tools can't act on a bad decision, but an agent with write tools can.

This category also carries one of FlowScan's three hard score caps: if an agent has critical-severity write-tool access and no iteration limit, AI Governance is capped at 35 regardless of what else the category's math would otherwise produce. See the Overview article for the other two caps.

Worked example: a workflow with one critical finding (an agent with write-capable tools reaching a destructive action) scores 100 − 30 = 70 before any cap is applied — but if the no-iteration-limit condition is also present, the cap forces the score down to 35 regardless.

Findings

Write-capable agent tools

Severity: high → critical. An agent that can only read and summarize is a fundamentally different risk than one that can send an email, update a record, or issue a refund based on its own reasoning. This finding fires whenever an agent is wired to a tool that changes state outside the workflow, and escalates further when that tool's write touches something public-facing, financial, or destructive — including when the write-capable agent is nested one level inside another agent.

Example: a customer-support agent has a tool that can issue refunds directly, with no approval step between the agent's decision and the refund actually being sent.

Fix: separate read and write tools across different agents where possible, and put an approval or validation step between an agent's reasoning and any write that's financial, destructive, or public-facing.

Untrusted input to a write-capable action

Severity: high → critical. This is the shape of a prompt-injection risk: something not fully trusted — a webhook payload, a scraped page, a forwarded email — becomes part of what an agent reasons over, and the agent has the ability to act on that reasoning by writing somewhere. This finding doesn't claim an injection attack happened; it flags that the path for one to succeed exists, with nothing in between to validate or constrain what the agent does with the input.

Example: an agent reads incoming email content to decide whether to update a customer's account, and the email body is passed into the agent's prompt unfiltered — a maliciously crafted email could attempt to influence the agent's decision.

Fix: validate or sanitize untrusted input before it enters an agent's prompt, and avoid connecting untrusted-input sources directly to write-capable agents without a check in between.

Shadow AI via generic HTTP calls

Severity: info. A third-party AI vendor is called through a generic HTTP request node instead of a recognized AI node type. Functionally it does the same thing a proper AI node would, but every other AI Governance check is blind to it — FlowScan can't evaluate write-tool access, iteration limits, or prompt content for a call it doesn't recognize as an AI call.

Example: a workflow calls an LLM provider's REST API directly through an HTTP Request node instead of using the platform's dedicated AI node.

Fix: route AI calls through recognized AI node types, both for governance visibility and because that's the only way other controls (token caps, structured output, iteration limits) can actually apply to the call.

Recommended fixes

1. Add an iteration limit to any agent that's missing one — this is usually a single configuration field, and it's the fastest way to bound worst-case behavior without removing capability.
2. Separate read-only and write-capable tools across different agents where the workflow allows it.
3. Add a validation or approval step between untrusted input and any write-capable action, especially anything financial, destructive, or public-facing.
4. Route third-party AI calls through recognized AI nodes instead of generic HTTP requests.

Related categories

• Cost Risk — the same iteration limits and tool-call counts, viewed as a spend multiplier rather than a governance risk
• Observability — what should happen after an agent's write goes wrong
• Overview — the hard cap that applies when write-capable agent tools combine with no iteration limit