Your Security Tool is Clippy. It Pops Up Unbidden, Offers Suggestions You Ignore, and Misses the One Thing That Matters.

✓ Human-authored analysis; AI used for formatting and proofreading.

Remember Clippy? Microsoft's paper clip assistant that popped up to ask: "It looks like you're writing a letter. Would you like help?"

Clippy was chatty, presumptuous, frequently wrong, and impossible to disable without effort. Clippy's design goal: be helpful. Clippy's actual effect: be annoying. The failure was the DESIGN MODEL. A helper agent that's always visible, always offering, always interpreting your actions as requests for assistance is categorically wrong for any domain where the user needs to focus.

Now look at your cloud security toolstack. Dashboards that surface 200 findings every scan. ML anomaly detectors that score every event. Alert pipelines that notify on every deviation. LLM copilots that offer suggestions for every finding. Each is Clippy that is chatty, presumptuous, always visible and offering. They were designed to be helpful. They produce the same failure: the operator ignores it until the one thing that matters is buried in the noise.

There's a design framework, Mann's Context-Perfect Agent that explains why the helper model fails and the correct model. The correct model is a circuit breaker.

Four dimensions of a coherent agent

The Context-Perfect Agent framework evaluates any system that acts on behalf of an outcome across four dimensions:

The fourth dimension makes the framework distinctive. Most agent-design frameworks aim for MAXIMUM helpfulness. The Context-Perfect Agent framework recognizes that too much helpfulness produces Clippy. The agent becomes nagging, presumptuous, intrusive. The agent must REFUSE certain forms of helpfulness to be coherent.

Dimension 1: Context is understanding meaning, not signals

A signal-driven system treats inputs at face value: the API says the bucket is public, so public bucket is the finding. A context-aware system treats inputs as EVIDENCE: the API says the bucket is public, AND this bucket is in the production account, AND the bucket's policy allows cross-account access, AND the IAM role that created it has permissions the operator didn't intend.

Four contextual assumptions baked into the architecture:

The most consequential: the system knows when it doesn't know enough. When the evidence is ambiguous, the system doesn't pretend certainty. It surfaces an AT_RISK verdict. The intermediate state between COMPLIANT and NON_COMPLIANT. AT_RISK says: "I see something concerning but I'm not certain. Investigate."

A system without AT_RISK has only binary verdicts and binary verdicts force the system to PRETEND certainty on ambiguous inputs. Every ML detector that produces a confidence score is pretending certainty (the score implies precision the model doesn't have). Every scanner that produces "Critical / High / Medium / Low" is pretending certainty. The severity implies knowledge of business impact the scanner doesn't have.

AT_RISK is explicit uncertainty. The operator knows when the system is sure and when it isn't. That transparency makes verdicts trustworthy.

Dimension 2: Perfection in engineering, not UX

Consumer software defines perfect by ADDING: more features, integrations, options and delight.

Engineering defines perfect by REMOVING: fewer unsafe transitions, smaller blast radius, earlier intervention, less human attention required.

Every metric is NEGATIVE. It reduces something that would otherwise be larger. The product gets more perfect by making things SMALLER. Fewer transitions. Smaller radius. Earlier. Less attention.

What the architecture refuses to optimize:

Each refusal is an explicit cost. Some operators WANT auto-approval. Some WANT ML inference. Some WANT post-incident automation. The architecture refuses each because each trades long-term safety for short-term convenience and the engineering definition of perfect is the one that reduces unsafe outcomes, not the one that increases user satisfaction.

Dimension 3: Agent is carefully limited

Six behavioral constraints:

Each constraint is ARCHITECTURAL, not configurable. The kernel doesn't have a notification subsystem (can't nag). Doesn't have an ML layer (can't guess). Doesn't have escalation rules (can't escalate). The absences are structural. They can't be turned on because they were never built.

The mental model: circuit breaker

The closest analogies:

Circuit breaker: Silent until current exceeds threshold. Then trips deterministically. No judgment, no negotiation, no "are you sure?" The circuit is open or closed.

Governor: Bounds the maximum rate. Intervenes only at the boundary. Does not advise on optimal rate within the boundary.

Safety interlock: Prevents operation outside safe conditions. Does not improve operation inside safe conditions.

The common pattern: boundary enforcement, not optimization. The system doesn't help inside the safe zone. It REFUSES to let you cross the boundary of the safe zone.

This is the structural opposite of a helper agent:

Each row is a structural inversion. The inversions aren't style choices. They make the system coherent in the safety-critical domain. A helper agent in a safety-critical domain is CATEGORICALLY wrong. Its behavior model contradicts the engineering requirements.

Dimension 4: Imperfection — the provocateur

The most distinctive dimension. The system must deliberately FAIL to be helpful in specific ways that FORCE better behavior elsewhere:

The provocation is uncomfortable but constructive. The developer who would have shipped the unsafe shortcut must now choose: take the supported path (more work, but safe) or escalate the invariant question to the catalog owner (slower, but explicit). Either choice produces BETTER systemic behavior than the shortcut would have.

Not annoying. Not frequent. Impossible to ignore.

Three properties that define the right provocateur:

Not annoying: Silent during safe operation. The developer forgets the system exists during normal weeks. No pop-ups. No suggestions. No "have you considered...?"

Not frequent: Invariant violations are rare in well-designed systems. The gate fires on the exceptional case, not the routine one. A team that sees the gate fire daily has a catalog problem, not a gate problem.

Impossible to ignore when it matters: When the gate fires, the pipeline blocks. The deployment CANNOT proceed. The developer MUST respond. Fix the IaC, update the catalog, or escalate to the catalog owner. There is no "dismiss" button. There is no "remind me later." The block is structural.

Clippy is the exact inverse: annoying (pops up unbidden), frequent (every paragraph), easy to ignore (close the assistant). The circuit breaker is: silent (invisible during normal operation), rare (fires on exceptions), impossible to ignore (pipeline blocks).

The validation test

A good Context-Perfect Agent is felt only in its absence.

Binary visibility: invisible OR unmistakable. Never in-between, "present but ignorable" or "absent when needed."

Tools that fail the test have either constant visibility (Clippy — visible even when not needed) or constant invisibility (observability without enforcement — invisible even when needed). The circuit breaker has neither failure mode because its visibility is CONDITIONAL on the system's state.

Teams that adopt the circuit breaker model report: they forget the system exists during normal weeks. When it fires, they respond immediately. Because the block is structural and the pipeline cannot proceed. Their discussions about the system happen at CATALOG-AUTHORING time (design time, when they're thinking about what "safe" means), not at RUNTIME (when they're trying to ship). The system is felt only in its absence when they think about what would have shipped without it.

The diagnostic for your tools

Test every tool in your security stack against the four dimensions:

Tools that fail one or more dimensions tend to degrade into helper-mode under pressure with more alerts, dashboards and suggestions. The vendor responds to "it's not working" with "let's show you more." The tool becomes noisier. The operator tunes it out. The one thing that matters gets buried.

Tools that pass all four dimensions maintain their position under pressure because their position is STRUCTURAL (boundary enforcement), not RELATIONAL (user satisfaction). The circuit breaker doesn't care if the user is happy. It cares if the circuit is safe.

Your security tool is Clippy. It pops up unbidden. It offers suggestions you ignore. It misses the one thing that matters because it's too busy showing you everything else. The correct model is the circuit breaker: silent until the threshold is crossed, then impossible to ignore. Because silence makes the signal trustworthy when it finally arrives.

The circuit breaker model with silent during safe operation, deterministic verdicts, acts only when invariants are violated, never nags, never guesses, impossible to ignore when it matters is implemented in Stave, an open-source Risk Reasoner. Not a helper. A circuit breaker. Try it: bash examples/demo-ai-security/run.sh