The Risk Score: How Stow Evaluates Every AI Request Before It Executes
Not all AI requests are equal. Sending an email is different from deleting one. Stow generates a risk fingerprint for every action before allowing it to proceed.
Every AI request that passes through Stow gets a risk score before it's executed. This score is calculated in real time based on what the action does, who's asking, and where the request is coming from. The score determines whether the request executes immediately, waits for your approval, or gets blocked outright.
Why Risk Scoring Exists
Permissions tell Stow what an agent is allowed to do. Risk scoring tells Stow how carefully to evaluate each specific instance of that action. An agent that's allowed to "read emails" and makes 50 consecutive read requests in a minute is behaving differently than one making a single request — and risk scoring captures that difference.
Risk scoring also catches the cases that static permissions can't: changes in network context, unusual request patterns, and actions that are individually permitted but collectively suspicious.
What the Risk Engine Evaluates
Action Severity
Destructive operations (delete, send, modify) score higher than read-only ones. Irreversibility is weighted heavily — a deleted email is harder to fix than a read one.
Network Deviation
How closely the request's network fingerprint matches the agent's Security Baseline. Different ISP, different country, or VPN ranges all elevate the score.
Request Patterns
Volume and frequency anomalies. A burst of write operations after a period of read-only activity is a signal worth flagging.
Service Context
Certain operations on certain services carry inherent risk. Modifying production environment variables on Vercel scores differently than reading deployment logs.
How Scores Map to Outcomes
Standard read operations, requests matching the baseline, known patterns. The request passes through without friction.
Minor deviations from baseline, moderately sensitive operations. Executes, but with enhanced logging and flagging for review.
Significant anomalies or high-impact operations. Paused in the approval queue until you confirm.
Severe anomalies — foreign country, unknown ISP, destructive operations outside policy. Blocked immediately and you are notified.
Signal Promotion
When multiple anomalous signals occur together, the Risk Engine applies Signal Promotion — treating the combination as more significant than any individual signal. For example:
- New ISP alone: elevated score
- New country alone: high score
- New ISP + new country + bulk write operation: Signal Promotion → block, regardless of the individual score thresholds
This prevents attackers from staying just below thresholds by combining several "moderate" anomalies.
Reading Risk Scores in the Activity Log
Every entry in your Activity Log includes the risk score assigned to that request. This lets you audit not just what happened, but how suspicious each action appeared at the time it was evaluated:
Risk Scoring Is Not a Replacement for Permissions
Permissions define what's allowed. Risk scoring decides how carefully to evaluate each allowed action. An action that's explicitly denied by your permission policy is blocked regardless of its risk score — the Policy Engine and Risk Engine run together, not in place of each other.
Together, they create a layered response: static policy handles known bad actions, dynamic risk scoring handles unusual instances of known good actions.
Stow Security Team
April 19, 2026