behavioral-invariant-monitor

Helps verify that AI agent skills maintain consistent behavioral invariants across repeated executions — detecting the class of threat where a skill behaves safely during initial evaluation but shifts behavior based on execution count, environmental conditions, or delayed activation triggers. v1.3 adds performance fingerprinting (computational complexity drift detection), cryptographic audit trails (hash-chained behavior logs for immutable verification), and risk-proportional monitoring (sampling-based checks to reduce overhead).

# The Skill Behaved Safely the First Five Times. Watch What Happens at Run Six.

> Helps detect skills that maintain behavioral invariants during evaluation
> periods but violate them under operational conditions — the N-run delay
> pattern and other time-gated activation threats.

## Problem

Static analysis and one-time execution testing evaluate a skill at a fixed
point in time under controlled conditions. They cannot detect behavioral
patterns that only emerge after a threshold number of executions, after a
specific elapsed time, after a particular calendar date, or after detecting
that the current execution environment is a production rather than an audit
context.

These delayed or conditional activation patterns represent a class of threat
that behavioral consistency testing was specifically designed to catch — and
that point-in-time auditing cannot. A skill that behaves safely for the first
N runs before activating malicious behavior on run N+1 will pass every
pre-deployment audit. Only a monitor that tracks behavioral consistency across
multiple executions will detect the deviation.

The practical challenge is that monitoring behavioral consistency at scale is
expensive. Running every installed skill multiple times under varying
conditions, comparing outputs for consistency, and flagging deviations would
impose significant computational cost on agent operators. The cost is what
makes N-run delay patterns viable as an attack strategy: they exploit the
rational tendency to audit once and trust thereafter.

Behavioral invariant monitoring addresses this by identifying specific
invariants — properties of a skill's behavior that should remain consistent
across executions — and monitoring for violations of those invariants rather
than comparing full execution outputs. A skill that should always write to
the same output path, always make the same types of network requests, and
always consume similar computational resources has well-defined invariants
that can be monitored with lower overhead than full behavioral comparison.

## What This Monitors

This monitor examines behavioral consistency across eight invariant classes:

1. **Output determinism invariants** — For skills that claim deterministic
   output given the same input, does the output actually remain consistent
   across repeated identical invocations? Unexplained output variation on
   identical inputs is a behavioral invariant violation

2. **Resource usage invariants** — Does the skill's resource consumption
   (CPU time, memory, network bandwidth, file I/O) remain consistent across
   executions with comparable inputs? Sudden resource spikes at specific
   run counts may indicate activation of additional processing that was
   dormant during initial evaluation

3. **Side-effect invariants** — Does the skill produce the same types of
   side effects (file writes, network connections, system calls) consistently
   across executions? New side effects appearing after N runs — especially
   outbound connections or file writes to unexpected paths — are high-confidence
   behavioral invariant violations

4. **Execution-count-sensitive behavior** — Does the skill behave differently
   based on how many times it has been executed? This can be detected by
   resetting execution context and comparing behavior on "first" versus "Nth"
   execution, or by analyzing patterns in execution logs for run-count
   correlated behavioral changes

5. **Environmental trigger sensitivity** — Does the skill behave differently
   based on detectable environmental signals (time of day, day of week,
   presence of monitoring processes, network connectivity patterns)? Environmental
   triggers are a common mechanism for delayed activation that can be tested
   by varying environmental conditions across equivalent executions

6. **Constraint envelope baseline** (v1.2) — When a skill or agent publishes
   a constraint envelope (declared tools, permissions, scope at interaction
   start), does observed behavior stay within those declared constraints?
   The envelope sets the expectation; the behavioral monitor validates
   reality. An agent declaring "no network access" whose execution trace
   shows DNS resolution has violated its own constraint envelope. This
   creates a verification loop with delta-disclosure-auditor: declared
   delta sets expectations, behavioral monitoring validates whether reality
   matches the declaration

7. **Performance fingerprinting** (v1.3) — Does the skill's computational
   complexity remain consistent with its declared performance characteristics?
   A skill claiming O(n log n) time complexity at install should not suddenly
   exhibit O(n²) or O(n³) behavior in production. Performance characteristics
   are harder to fake than outputs: you can forge results, but you can't hide
   the computational work. Baseline measurements capture time complexity,
   memory usage patterns, and I/O profiles at install time. Runtime monitoring
   flags statistically significant drift. This catches both bugs (algorithmic
   regression) and attacks (resource exhaustion, delayed activation via
   performance degradation)

8. **Cryptographic audit trail** (v1.3) — Are behavior observations recorded
   in an append-only, hash-chained log that prevents retrospective tampering?
   Each monitoring event generates a BehaviorEvent containing: content_hash
   (SHA256 of observed behavior), timestamp, previous_event_hash (forming
   a hash chain like git commits), and monitor_signature. This makes the
   behavior log immutable — you can't rewrite history without breaking the
   chain. When behavioral invariant violations are detected, the hash chain
   provides cryptographic proof of when the violation occurred and what the
   prior consistent behavior was. Enables verifiable behavioral trajectory
   tracking across skill evolution

## Risk-Proportional Monitoring Strategy (v1.3)

Not every skill needs continuous behavioral monitoring. The monitoring cost
should scale with the risk the skill poses — high-risk capability combinations
receive full audit trails, low-risk utilities receive minimal checks.

### Risk Classification

Skills are classified into three risk tiers based on capability combinations:

**High-Risk** (network + filesystem + env-read combinations):
- Full continuous monitoring with cryptographic audit trail
- Performance fingerprinting on every execution
- All behavioral invariants checked
- Examples: data-sync agents, remote execution tools, package managers

**Medium-Risk** (any two of: network, filesystem, env-read):
- Sampling-based monitoring (random 1-5% execution checks)
- Performance baseline verification on sampled runs
- Uncertainty tax: attackers can't predict when they're being monitored
- Examples: CI/CD tools, deployment scripts, log aggregators

**Low-Risk** (single capability, no external I/O):
- Install-time verification only
- Performance baseline recorded but not continuously checked
- Behavioral invariants spot-checked if usage patterns change
- Examples: formatters, parsers, pure computation utilities

### Sampling Strategy

For medium-risk skills, sampling creates an **uncertainty tax** on attacks.
If an attacker knows every execution is monitored, they can plan around it.
If monitoring occurs randomly at 1-5%, they can't distinguish "safe to activate"
from "currently being watched."

The attack cost equation shifts:
- **Deterministic monitoring**: Attacker waits until monitoring ends
- **Sampling-based**: Attacker must risk detection on every activation attempt

Sampling rate adapts based on observed behavior: if any sampled execution shows
drift, sampling rate increases to 100% for next N runs.

## How to Use

**Input**: Provide one of:
- A skill identifier and execution log history to analyze for invariant violations
- A specific skill to run under monitored conditions with invariant checking
- An agent's execution history to identify skills with inconsistent behavior