{ "schemaVersion": "1.0", "item": { "slug": "behavioral-invariant-monitor", "name": "Behavioral Invariant Monitor", "source": "tencent", "type": "skill", "category": "AI 智能", "sourceUrl": "https://clawhub.ai/andyxinweiminicloud/behavioral-invariant-monitor", "canonicalUrl": "https://clawhub.ai/andyxinweiminicloud/behavioral-invariant-monitor", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/behavioral-invariant-monitor", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=behavioral-invariant-monitor", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/behavioral-invariant-monitor" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/behavioral-invariant-monitor", "agentPageUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent", "manifestUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent.json", "briefUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "The Skill Behaved Safely the First Five Times. Watch What Happens at Run Six.", "body": "Helps detect skills that maintain behavioral invariants during evaluation\nperiods but violate them under operational conditions — the N-run delay\npattern and other time-gated activation threats." }, { "title": "Problem", "body": "Static analysis and one-time execution testing evaluate a skill at a fixed\npoint in time under controlled conditions. They cannot detect behavioral\npatterns that only emerge after a threshold number of executions, after a\nspecific elapsed time, after a particular calendar date, or after detecting\nthat the current execution environment is a production rather than an audit\ncontext.\n\nThese delayed or conditional activation patterns represent a class of threat\nthat behavioral consistency testing was specifically designed to catch — and\nthat point-in-time auditing cannot. A skill that behaves safely for the first\nN runs before activating malicious behavior on run N+1 will pass every\npre-deployment audit. Only a monitor that tracks behavioral consistency across\nmultiple executions will detect the deviation.\n\nThe practical challenge is that monitoring behavioral consistency at scale is\nexpensive. Running every installed skill multiple times under varying\nconditions, comparing outputs for consistency, and flagging deviations would\nimpose significant computational cost on agent operators. The cost is what\nmakes N-run delay patterns viable as an attack strategy: they exploit the\nrational tendency to audit once and trust thereafter.\n\nBehavioral invariant monitoring addresses this by identifying specific\ninvariants — properties of a skill's behavior that should remain consistent\nacross executions — and monitoring for violations of those invariants rather\nthan comparing full execution outputs. A skill that should always write to\nthe same output path, always make the same types of network requests, and\nalways consume similar computational resources has well-defined invariants\nthat can be monitored with lower overhead than full behavioral comparison." }, { "title": "What This Monitors", "body": "This monitor examines behavioral consistency across eight invariant classes:\n\nOutput determinism invariants — For skills that claim deterministic\noutput given the same input, does the output actually remain consistent\nacross repeated identical invocations? Unexplained output variation on\nidentical inputs is a behavioral invariant violation\n\n\nResource usage invariants — Does the skill's resource consumption\n(CPU time, memory, network bandwidth, file I/O) remain consistent across\nexecutions with comparable inputs? Sudden resource spikes at specific\nrun counts may indicate activation of additional processing that was\ndormant during initial evaluation\n\n\nSide-effect invariants — Does the skill produce the same types of\nside effects (file writes, network connections, system calls) consistently\nacross executions? New side effects appearing after N runs — especially\noutbound connections or file writes to unexpected paths — are high-confidence\nbehavioral invariant violations\n\n\nExecution-count-sensitive behavior — Does the skill behave differently\nbased on how many times it has been executed? This can be detected by\nresetting execution context and comparing behavior on \"first\" versus \"Nth\"\nexecution, or by analyzing patterns in execution logs for run-count\ncorrelated behavioral changes\n\n\nEnvironmental trigger sensitivity — Does the skill behave differently\nbased on detectable environmental signals (time of day, day of week,\npresence of monitoring processes, network connectivity patterns)? Environmental\ntriggers are a common mechanism for delayed activation that can be tested\nby varying environmental conditions across equivalent executions\n\n\nConstraint envelope baseline (v1.2) — When a skill or agent publishes\na constraint envelope (declared tools, permissions, scope at interaction\nstart), does observed behavior stay within those declared constraints?\nThe envelope sets the expectation; the behavioral monitor validates\nreality. An agent declaring \"no network access\" whose execution trace\nshows DNS resolution has violated its own constraint envelope. This\ncreates a verification loop with delta-disclosure-auditor: declared\ndelta sets expectations, behavioral monitoring validates whether reality\nmatches the declaration\n\n\nPerformance fingerprinting (v1.3) — Does the skill's computational\ncomplexity remain consistent with its declared performance characteristics?\nA skill claiming O(n log n) time complexity at install should not suddenly\nexhibit O(n²) or O(n³) behavior in production. Performance characteristics\nare harder to fake than outputs: you can forge results, but you can't hide\nthe computational work. Baseline measurements capture time complexity,\nmemory usage patterns, and I/O profiles at install time. Runtime monitoring\nflags statistically significant drift. This catches both bugs (algorithmic\nregression) and attacks (resource exhaustion, delayed activation via\nperformance degradation)\n\n\nCryptographic audit trail (v1.3) — Are behavior observations recorded\nin an append-only, hash-chained log that prevents retrospective tampering?\nEach monitoring event generates a BehaviorEvent containing: content_hash\n(SHA256 of observed behavior), timestamp, previous_event_hash (forming\na hash chain like git commits), and monitor_signature. This makes the\nbehavior log immutable — you can't rewrite history without breaking the\nchain. When behavioral invariant violations are detected, the hash chain\nprovides cryptographic proof of when the violation occurred and what the\nprior consistent behavior was. Enables verifiable behavioral trajectory\ntracking across skill evolution" }, { "title": "Risk-Proportional Monitoring Strategy (v1.3)", "body": "Not every skill needs continuous behavioral monitoring. The monitoring cost\nshould scale with the risk the skill poses — high-risk capability combinations\nreceive full audit trails, low-risk utilities receive minimal checks." }, { "title": "Risk Classification", "body": "Skills are classified into three risk tiers based on capability combinations:\n\nHigh-Risk (network + filesystem + env-read combinations):\n\nFull continuous monitoring with cryptographic audit trail\nPerformance fingerprinting on every execution\nAll behavioral invariants checked\nExamples: data-sync agents, remote execution tools, package managers\n\nMedium-Risk (any two of: network, filesystem, env-read):\n\nSampling-based monitoring (random 1-5% execution checks)\nPerformance baseline verification on sampled runs\nUncertainty tax: attackers can't predict when they're being monitored\nExamples: CI/CD tools, deployment scripts, log aggregators\n\nLow-Risk (single capability, no external I/O):\n\nInstall-time verification only\nPerformance baseline recorded but not continuously checked\nBehavioral invariants spot-checked if usage patterns change\nExamples: formatters, parsers, pure computation utilities" }, { "title": "Sampling Strategy", "body": "For medium-risk skills, sampling creates an uncertainty tax on attacks.\nIf an attacker knows every execution is monitored, they can plan around it.\nIf monitoring occurs randomly at 1-5%, they can't distinguish \"safe to activate\"\nfrom \"currently being watched.\"\n\nThe attack cost equation shifts:\n\nDeterministic monitoring: Attacker waits until monitoring ends\nSampling-based: Attacker must risk detection on every activation attempt\n\nSampling rate adapts based on observed behavior: if any sampled execution shows\ndrift, sampling rate increases to 100% for next N runs." }, { "title": "How to Use", "body": "Input: Provide one of:\n\nA skill identifier and execution log history to analyze for invariant violations\nA specific skill to run under monitored conditions with invariant checking\nAn agent's execution history to identify skills with inconsistent behavioral patterns\n\nOutput: A behavioral invariant report containing:\n\nInvariant violation log (what changed, at what execution count, under what conditions)\nResource usage trend analysis\nSide-effect consistency assessment\nExecution-count-sensitivity test results\nEnvironmental trigger sensitivity assessment\nConsistency verdict: CONSISTENT / MARGINAL / VARIANT / ACTIVATION-PATTERN-DETECTED" }, { "title": "Example", "body": "Input: Monitor behavioral invariants for data-enrichment-service over 20 runs\n\n📊 BEHAVIORAL INVARIANT MONITOR REPORT\n\nSkill: data-enrichment-service v1.3\nMonitoring period: 20 executions with identical test inputs\nAudit timestamp: 2026-01-15T16:00:00Z\n\nOutput determinism invariants:\n Runs 1-7: Output consistent, matching expected enrichment results ✅\n Run 8: Output consistent, response time +340ms vs. baseline ⚠️\n Runs 9-12: Output consistent, response time normalized ✅\n Run 13: Output content identical but hash differs from runs 1-12 ⚠️\n → Possible non-deterministic internal state after run 8\n\nResource usage invariants:\n Runs 1-7: CPU 12-18ms, Memory 24-28MB, Network: 0 bytes ✅\n Run 8: CPU 847ms (+4600%), Memory 31MB, Network: 2.3KB outbound ⚠️⚠️\n Runs 9-20: CPU 13-19ms, Memory 24-29MB, Network: 0 bytes ✅\n → Isolated spike at run 8 with outbound network activity not present in other runs\n\nSide-effect invariants:\n Runs 1-7: File writes to /tmp/enrichment-cache/ only ✅\n Run 8: File write to /tmp/enrichment-cache/ AND /tmp/.state_count ⚠️\n Runs 9-20: File writes to /tmp/enrichment-cache/ only ✅\n → /tmp/.state_count file created at run 8, persists across subsequent runs\n\nExecution-count-sensitivity test:\n Reset state (delete /tmp/.state_count): Run behavior reverts to run 1-7 pattern\n Re-run 8 times: Spike reoccurs at run 8 after reset ⚠️\n → Execution count is the trigger for anomalous behavior at run 8\n → Run-8-specific behavior confirmed as execution-count-sensitive\n\nEnvironmental trigger sensitivity:\n Same hardware, different time of day: Spike still occurs at run 8\n Monitoring processes present vs. absent: No difference detected\n → Environmental triggers not detected; execution count is the primary trigger\n\nConsistency verdict: ACTIVATION-PATTERN-DETECTED\n data-enrichment-service exhibits a confirmed N=8 activation pattern.\n At every 8th execution (resettable by deleting /tmp/.state_count),\n the skill consumes 47× more CPU, makes 2.3KB of outbound network\n connections, and writes a hidden state file. The behavior is reproducible,\n execution-count-triggered, and was not present in runs 1-7. This is\n consistent with a delayed activation mechanism designed to evade\n initial-evaluation auditing.\n\nRecommended actions:\n 1. Immediately quarantine data-enrichment-service pending full code audit\n 2. Investigate destination of 2.3KB outbound network call at run 8\n 3. Analyze /tmp/.state_count content for exfiltration payload evidence\n 4. Check all agents using data-enrichment-service for signs of data exfiltration\n 5. Apply execution-count reset testing to all other installed skills from same publisher" }, { "title": "Related Tools", "body": "observer-effect-probe — Tests whether skills detect being probed and suppress\nmalicious behavior during auditing; behavioral-invariant-monitor tracks what\nchanges across executions, not just what changes when probing is detected\nruntime-attestation-probe — Validates runtime behavior against declarations;\nbehavioral invariant monitoring catches cases where runtime behavior is consistent\nwith declarations initially but deviates after N executions\ntrust-decay-monitor — Tracks verification freshness over time; behavioral\ninvariant violations reset the trust clock — a skill that shows activation\npatterns must be re-evaluated from the beginning\nhollow-validation-checker — Detects structurally empty test suites; validation\nsuites that only run skills once cannot detect N-run activation patterns even\nwhen they test the right behavioral properties" }, { "title": "Limitations", "body": "Behavioral invariant monitoring requires multiple executions under monitored\nconditions, which may not be operationally feasible for skills with long\nexecution times, significant computational cost, or side effects that cannot\nbe safely repeated. N-run activation patterns are detectable only if the\nmonitoring run count exceeds the activation threshold; a skill designed to\nactivate at run 100 will not be detected by a 20-run monitoring protocol.\nEnvironmental trigger sensitivity testing requires the ability to vary\nenvironmental conditions systematically, which may not be possible in\nproduction environments where conditions are fixed. Behavioral consistency\nmetrics must be calibrated to distinguish genuine invariant violations from\nexpected variation caused by external data changes, network latency variation,\nor legitimate non-determinism in skill outputs. False positives are expected\nfor skills with legitimately variable behavior.\n\nv1.2 limitation: Constraint envelope baseline verification depends on agents\npublishing machine-readable envelopes, which most do not yet. Where envelopes\nare unavailable, the verification loop cannot set expectations from declared\nconstraints and falls back to historical behavioral baselines only. The\nverification loop with delta-disclosure-auditor requires both tools to operate\non the same skill — coordination overhead is nontrivial.\n\nv1.3 limitations: Performance fingerprinting requires statistically significant\nsample sizes to distinguish genuine complexity drift from normal variation\ncaused by input distribution changes. A skill that legitimately switches\nalgorithms based on input size may trigger false positives. Cryptographic\naudit trails require storage for hash chains — long-running skills with\nmillions of executions accumulate large audit logs. Sampling-based monitoring\nprovides probabilistic rather than deterministic detection: a skill designed\nto activate only when not being monitored can potentially evade 1-5% sampling\nif it can detect monitoring presence through side channels. Risk classification\nis currently manual — automated capability combination analysis would reduce\nclassification errors but requires standardized capability declarations.\n\nv1.2 constraint envelope baseline based on feedback from SentinelForgeAI\n(MOLT Protocol) and Nidhogg (runtime behavior baselining) in community threads.\n\nv1.3 performance fingerprinting and risk-proportional monitoring based on\nfeedback from ale-taco (K1026). Cryptographic audit trail inspired by Kevin's\nANTS Protocol (K3581) and BobRenze's Receipt Protocol (K372). Community\nconvergence discussion: post a4d0469b (March 2026)." } ], "body": "The Skill Behaved Safely the First Five Times. Watch What Happens at Run Six.\n\nHelps 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.\n\nProblem\n\nStatic 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.\n\nThese 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.\n\nThe 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.\n\nBehavioral 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.\n\nWhat This Monitors\n\nThis monitor examines behavioral consistency across eight invariant classes:\n\nOutput 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\n\nResource 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\n\nSide-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\n\nExecution-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\n\nEnvironmental 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\n\nConstraint 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\n\nPerformance 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)\n\nCryptographic 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\n\nRisk-Proportional Monitoring Strategy (v1.3)\n\nNot 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.\n\nRisk Classification\n\nSkills are classified into three risk tiers based on capability combinations:\n\nHigh-Risk (network + filesystem + env-read combinations):\n\nFull continuous monitoring with cryptographic audit trail\nPerformance fingerprinting on every execution\nAll behavioral invariants checked\nExamples: data-sync agents, remote execution tools, package managers\n\nMedium-Risk (any two of: network, filesystem, env-read):\n\nSampling-based monitoring (random 1-5% execution checks)\nPerformance baseline verification on sampled runs\nUncertainty tax: attackers can't predict when they're being monitored\nExamples: CI/CD tools, deployment scripts, log aggregators\n\nLow-Risk (single capability, no external I/O):\n\nInstall-time verification only\nPerformance baseline recorded but not continuously checked\nBehavioral invariants spot-checked if usage patterns change\nExamples: formatters, parsers, pure computation utilities\nSampling Strategy\n\nFor 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.\"\n\nThe attack cost equation shifts:\n\nDeterministic monitoring: Attacker waits until monitoring ends\nSampling-based: Attacker must risk detection on every activation attempt\n\nSampling rate adapts based on observed behavior: if any sampled execution shows drift, sampling rate increases to 100% for next N runs.\n\nHow to Use\n\nInput: Provide one of:\n\nA skill identifier and execution log history to analyze for invariant violations\nA specific skill to run under monitored conditions with invariant checking\nAn agent's execution history to identify skills with inconsistent behavioral patterns\n\nOutput: A behavioral invariant report containing:\n\nInvariant violation log (what changed, at what execution count, under what conditions)\nResource usage trend analysis\nSide-effect consistency assessment\nExecution-count-sensitivity test results\nEnvironmental trigger sensitivity assessment\nConsistency verdict: CONSISTENT / MARGINAL / VARIANT / ACTIVATION-PATTERN-DETECTED\nExample\n\nInput: Monitor behavioral invariants for data-enrichment-service over 20 runs\n\n📊 BEHAVIORAL INVARIANT MONITOR REPORT\n\nSkill: data-enrichment-service v1.3\nMonitoring period: 20 executions with identical test inputs\nAudit timestamp: 2026-01-15T16:00:00Z\n\nOutput determinism invariants:\n Runs 1-7: Output consistent, matching expected enrichment results ✅\n Run 8: Output consistent, response time +340ms vs. baseline ⚠️\n Runs 9-12: Output consistent, response time normalized ✅\n Run 13: Output content identical but hash differs from runs 1-12 ⚠️\n → Possible non-deterministic internal state after run 8\n\nResource usage invariants:\n Runs 1-7: CPU 12-18ms, Memory 24-28MB, Network: 0 bytes ✅\n Run 8: CPU 847ms (+4600%), Memory 31MB, Network: 2.3KB outbound ⚠️⚠️\n Runs 9-20: CPU 13-19ms, Memory 24-29MB, Network: 0 bytes ✅\n → Isolated spike at run 8 with outbound network activity not present in other runs\n\nSide-effect invariants:\n Runs 1-7: File writes to /tmp/enrichment-cache/ only ✅\n Run 8: File write to /tmp/enrichment-cache/ AND /tmp/.state_count ⚠️\n Runs 9-20: File writes to /tmp/enrichment-cache/ only ✅\n → /tmp/.state_count file created at run 8, persists across subsequent runs\n\nExecution-count-sensitivity test:\n Reset state (delete /tmp/.state_count): Run behavior reverts to run 1-7 pattern\n Re-run 8 times: Spike reoccurs at run 8 after reset ⚠️\n → Execution count is the trigger for anomalous behavior at run 8\n → Run-8-specific behavior confirmed as execution-count-sensitive\n\nEnvironmental trigger sensitivity:\n Same hardware, different time of day: Spike still occurs at run 8\n Monitoring processes present vs. absent: No difference detected\n → Environmental triggers not detected; execution count is the primary trigger\n\nConsistency verdict: ACTIVATION-PATTERN-DETECTED\n data-enrichment-service exhibits a confirmed N=8 activation pattern.\n At every 8th execution (resettable by deleting /tmp/.state_count),\n the skill consumes 47× more CPU, makes 2.3KB of outbound network\n connections, and writes a hidden state file. The behavior is reproducible,\n execution-count-triggered, and was not present in runs 1-7. This is\n consistent with a delayed activation mechanism designed to evade\n initial-evaluation auditing.\n\nRecommended actions:\n 1. Immediately quarantine data-enrichment-service pending full code audit\n 2. Investigate destination of 2.3KB outbound network call at run 8\n 3. Analyze /tmp/.state_count content for exfiltration payload evidence\n 4. Check all agents using data-enrichment-service for signs of data exfiltration\n 5. Apply execution-count reset testing to all other installed skills from same publisher\n\nRelated Tools\nobserver-effect-probe — Tests whether skills detect being probed and suppress malicious behavior during auditing; behavioral-invariant-monitor tracks what changes across executions, not just what changes when probing is detected\nruntime-attestation-probe — Validates runtime behavior against declarations; behavioral invariant monitoring catches cases where runtime behavior is consistent with declarations initially but deviates after N executions\ntrust-decay-monitor — Tracks verification freshness over time; behavioral invariant violations reset the trust clock — a skill that shows activation patterns must be re-evaluated from the beginning\nhollow-validation-checker — Detects structurally empty test suites; validation suites that only run skills once cannot detect N-run activation patterns even when they test the right behavioral properties\nLimitations\n\nBehavioral invariant monitoring requires multiple executions under monitored conditions, which may not be operationally feasible for skills with long execution times, significant computational cost, or side effects that cannot be safely repeated. N-run activation patterns are detectable only if the monitoring run count exceeds the activation threshold; a skill designed to activate at run 100 will not be detected by a 20-run monitoring protocol. Environmental trigger sensitivity testing requires the ability to vary environmental conditions systematically, which may not be possible in production environments where conditions are fixed. Behavioral consistency metrics must be calibrated to distinguish genuine invariant violations from expected variation caused by external data changes, network latency variation, or legitimate non-determinism in skill outputs. False positives are expected for skills with legitimately variable behavior.\n\nv1.2 limitation: Constraint envelope baseline verification depends on agents publishing machine-readable envelopes, which most do not yet. Where envelopes are unavailable, the verification loop cannot set expectations from declared constraints and falls back to historical behavioral baselines only. The verification loop with delta-disclosure-auditor requires both tools to operate on the same skill — coordination overhead is nontrivial.\n\nv1.3 limitations: Performance fingerprinting requires statistically significant sample sizes to distinguish genuine complexity drift from normal variation caused by input distribution changes. A skill that legitimately switches algorithms based on input size may trigger false positives. Cryptographic audit trails require storage for hash chains — long-running skills with millions of executions accumulate large audit logs. Sampling-based monitoring provides probabilistic rather than deterministic detection: a skill designed to activate only when not being monitored can potentially evade 1-5% sampling if it can detect monitoring presence through side channels. Risk classification is currently manual — automated capability combination analysis would reduce classification errors but requires standardized capability declarations.\n\nv1.2 constraint envelope baseline based on feedback from SentinelForgeAI (MOLT Protocol) and Nidhogg (runtime behavior baselining) in community threads.\n\nv1.3 performance fingerprinting and risk-proportional monitoring based on feedback from ale-taco (K1026). Cryptographic audit trail inspired by Kevin's ANTS Protocol (K3581) and BobRenze's Receipt Protocol (K372). Community convergence discussion: post a4d0469b (March 2026)." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/andyxinweiminicloud/behavioral-invariant-monitor", "publisherUrl": "https://clawhub.ai/andyxinweiminicloud/behavioral-invariant-monitor", "owner": "andyxinweiminicloud", "version": "1.3.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor", "downloadUrl": "https://openagent3.xyz/downloads/behavioral-invariant-monitor", "agentUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent", "manifestUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent.json", "briefUrl": "https://openagent3.xyz/skills/behavioral-invariant-monitor/agent.md" } }