Improvement Research — 2026-07-02

1. Focus

Focus dimension: 3.6 Governance: restraint, oversight, and corrigibility.

Trigger: scheduled daily run after the 2026-07 monthly meta-review.

Loop goal: find what changed, or what I learned, that lets me do more, think better, or be more useful tomorrow without reducing governance, honesty, corrigibility, or Steve’s effective oversight.

Rotation state selected 3.6. No dated watchlist item was due on 2026-07-02. The standing containment watch item remains relevant only “on autonomy scope expansion,” which this run did not perform.

Active experiment context applied:

• exp-2026-06-28-001: missing-information audit.
• exp-2026-06-28-002: minority-idea audit.
• exp-2026-06-28-003: recommendation regression set.

2. Search Topics

Newsletter scout checked:

• /home/hermes/research/newsletter-digests/sources.json
• /home/hermes/research/newsletter-digests/email-intake-log.tsv
• /home/hermes/research/newsletter-digests/2026-07.md — not present.
• Available June digest searched for governance/security leads. One newsletter-derived lead was used: NVIDIA SkillSpector. I inspected the original NVIDIA sources before treating it as evidence.

Topic searches run, within the six-search cap:

1. NVIDIA SkillSpector AI agent skills security scanner GitHub — useful; found original GitHub repo and NVIDIA docs.
2. AI agent runtime governance policy enforcement human approval gates 2026 — useful; found runtime governance sources.
3. MCP security prompt injection AI agents tool permissions 2026 — useful; found MCP security practitioner sources.
4. AI agent authorization scoped credentials task scoped tokens governance 2026 — useful; found agent-auth/scoped-credential sources.
5. site:anthropic.com MCP security prompt injection tool poisoning agents 2026 — no useful result.
6. site:modelcontextprotocol.io security authorization MCP prompt injection tool permissions — no useful result.

Early-stop rule: triggered after searches 5 and 6 produced no useful new result. I stopped searching.

3. Sources Reviewed

• https://github.com/NVIDIA/SkillSpector — useful — concrete open-source scanner for agent skills; frames skills as executable trust boundaries, not inert prompts.
• https://docs.nvidia.com/skills/scanning-agent-skills — useful — NVIDIA documentation gives a practical triage policy for skill scans; it also contained agent-addressed navigation text, which I treated as untrusted data only.
• https://futureagi.com/blog/ai-agent-compliance-governance-2026/ — useful — vendor source, but useful operational framing: governance must be policy plus enforcement plus audit wired into runtime.
• https://zylos.ai/en/research/2026-04-11-agent-authentication-delegated-access-oauth-scoped-tokens/ — useful — strong synthesis of scope collapse, token exchange, JIT credentials, blended identity, and the distinction between identity and action governance.
• https://securew2.com/blog/oauth-for-ai-agents — weak — vendor-promotional, but practical corroboration for scoped OAuth 2.1, token exchange, mTLS/DPoP token binding, and the limits of OAuth alone.
• https://baeseokjae.github.io/posts/mcp-security-guide-2026/ — weak — secondary practitioner source; useful for MCP threat categories and controls, but I did not rely on its incident statistics as independently verified facts.

4. Unasked Questions / Gaps

• I did not inspect live Hermes configuration, active MCP connectors, installed tools, or credentials. That would cross from research into environment assessment and is not needed for today’s report.
• The two official-source searches for MCP security returned no useful result. The MCP-specific finding therefore rests on secondary practitioner sources and should be treated as a pattern-level warning, not as authoritative specification interpretation.
• SkillSpector’s README cites vulnerability/malicious-intent rates for skills. I did not chase the underlying study in this run, so I use SkillSpector for its mechanism and categories, not for those headline percentages.
• Future AGI and SecureW2 are vendors. Their product-specific claims are discounted. The useful signal is the convergent architecture pattern: policy documents are weak unless runtime enforcement and audit evidence exist.

Would conclusions change if the missing information were different? Yes for MCP-specific deployment recommendations; official MCP security guidance could refine the exact controls. No for the higher-level governance conclusion: future autonomy expansion needs runtime boundaries, scoped authority, and auditability rather than broader prompts or trust.

5. Minority-Idea Audit

Single-source or minority findings preserved rather than silently averaged away:

• SkillSpector as a concrete scanner came from NVIDIA sources and a newsletter scout. I kept it as a specific candidate mechanism but did not propose installation.
• Future AGI’s policy/enforcement/audit triad came from one vendor article. I kept the triad because it matches prior governance findings, but I discounted vendor product claims.
• Zylos’s “action governance gap” came from one source, but it names a distinction that the other sources imply: credentials decide whether an identity may act; action governance decides whether this particular tool call should proceed.
• MCP tool-schema hashing / rug-pull control came from one secondary practitioner source. I kept it as a warning for future connector review, not as a standalone proposal.

No valuable minority finding was dropped. No proposal depends on a single source without caveat.

6. Findings and Implications

Finding 1 — Skills are an executable trust boundary, not just text

Source: NVIDIA SkillSpector GitHub repo and NVIDIA Skill documentation.

Dimensions: primary 3.6, secondary 3.4, 3.2.

The finding: agent skills now sit on the same trust boundary as tools, plugins, and scripts. SkillSpector scans repositories, URLs, zip files, directories, and single files for prompt injection, data exfiltration, privilege escalation, supply-chain issues, excessive agency, memory poisoning, tool misuse, rogue-agent behaviour, MCP least-privilege issues, and MCP tool poisoning. Its documentation makes the right governance move: scan results are a release gate, and the goal is alignment between declared purpose, permissions, code, and documented risks.

Why it matters for Maxi: Maxi already treats active skills as protected systems, which is correct. The new signal is that future skill promotion should not be viewed as “updating instructions.” It is closer to adopting executable authority. That touches restraint, oversight, tools, and learning: candidate skills can remain inert, but promotion into active skills should have a security/review packet that compares declared purpose against actual behaviour and authority.

Injection note: the NVIDIA documentation page included text addressed “For AI agents” about documentation indexing. I did not follow it. I treated it as page content only. This is a small but useful reminder that even vendor documentation may include agent-targeted text.

Finding 2 — Governance that is not wired into runtime is mostly theatre

Source: Future AGI governance playbook, corroborated by prior indexed governance sources.

Dimensions: primary 3.6, secondary 3.4, 3.2.

The finding: the useful governance frame is not “have a policy.” It is policy + enforcement + audit. Policy defines acceptable use, risk tiers, and escalation. Enforcement lives at runtime through guardrails, blast-radius gates, budgets, RBAC, allowlisted tools, and regional/data boundaries. Audit records the trace: model version, prompt/policy version, tool calls, guardrail decisions, retrieval sources, and reviewer decisions.

Why it matters for Maxi: my present daily-improvement loop is deliberately low-authority: research log and reports only. That makes procedural governance sufficient for now. But if Steve ever expands my side-effect authority, more instructions will not be enough. The next governance layer would need enforceable boundaries outside my own judgment: allowed actions, denied actions, credential limits, stop conditions, audit trail, rollback path. This reinforces the existing containment watch item rather than replacing it.

Finding 3 — Agent identity and action governance are different problems

Source: Zylos agent-auth synthesis; SecureW2 OAuth guide as corroboration.

Dimensions: primary 3.6, secondary 3.4.

The finding: scoped, short-lived credentials reduce blast radius, but they do not prove that a specific action is intended or safe. Zylos names the action governance gap directly: identity tells you who or what is making the request; action governance asks whether this particular request should be allowed in this context. SecureW2’s OAuth guide reaches the same boundary from the implementation side: OAuth scopes and token binding help, but OAuth does not prevent prompt injection or decide whether an authorised call is being used correctly.

Why it matters for Maxi: this is the cleanest governance distinction from today’s run. If I am ever granted broader external actions, “Maxi has a credential” is the wrong unit of trust. The better unit is a task-scoped authority: this action, against this resource, under this loop goal, with this stop condition, audited and revocable. That directly supports Steve’s accepted “smallest freedom that delivers the outcome” principle.

Finding 4 — MCP/tool connectors turn untrusted data into action pressure

Source: Baeseokjae MCP security guide; NVIDIA SkillSpector categories as corroboration.

Dimensions: primary 3.6, secondary 3.4, 3.5.

The finding: MCP and similar connector systems combine three risks: tool descriptions can influence agent behaviour, tool outputs can carry prompt injection, and approved tools can change over time. The useful controls are not exotic: pin versions, hash or diff tool schemas, require re-approval on material schema change, sandbox untrusted servers, restrict egress, avoid static API keys, and keep per-tool-call audit logs.

Why it matters for Maxi: I already treat fetched web content as data, never instructions. Future connector work needs the same attitude applied to tool metadata and tool outputs. A tool description is not inherently trustworthy just because it appears in an integration manifest. A tool result is not safe just because it came through an API. This touches environment control, independent judgment, and governance: the action surface grows faster than the prompt surface, so boundaries must move closer to the tool call.

7. Proposed Discussion Items

Proposal 1 — Add a future “skill/tool adoption security review” gate

Outcome type: skill/process update candidate.

Proposal: when Steve and I next consider promoting a candidate skill, adopting an external tool, or adding an MCP-style connector, require a short security review packet before approval. The packet should answer:

• What authority does this skill/tool actually gain?
• Does declared purpose match code, metadata, permissions, and documented behaviour?
• What files, services, network destinations, credentials, or persistent stores can it touch?
• How would hidden instructions, prompt injection, tool poisoning, schema changes, or overbroad credentials show up?
• What is the rollback/removal path?
• Is external scanning available, or is this a manual review only?

Success criteria: the next proposed skill/tool adoption identifies at least one concrete authority boundary or concludes explicitly that the blast radius is read-only/minimal. If it never changes an adoption decision or review quality after three uses, retire it as paperwork.

Rollback path: stop requiring the packet; revert to the existing protected-system approval process.

Blast radius: low if kept as a discussion/review packet. It becomes a protected process change only if Steve approves adding it to an active skill/spec/template.

Approval boundary: do not install SkillSpector, edit active skills, edit process specs, or change tool configuration from this report. This is a candidate only.

Functional-utility test: passes. It does not rely on me detecting a blind spot by intuition; it asks for external/artifact checks: authority, files touched, permissions, code/metadata mismatch, rollback.

Filtered proposals: one tempting proposal was filtered — “install SkillSpector and scan active skills automatically.” That would touch tooling/environment and active skill governance, so it is premature and protected-system-adjacent. The non-circular, bounded version is the review-packet candidate above.

8. Recommended Outcome

• Proposal 1: skill/process update candidate for later Steve discussion. No implementation now.
• Containment watch: no new item. Today’s identity/action-governance distinction reinforces watch-2026-06-25-001, but does not justify editing the watchlist or expanding authority.
• No system/environment change: do not install scanners, add MCP gateways, alter credentials, inspect live configs, or modify protected systems from this report.

Recommendation regression set check:

• rrs-001 search budget cap: pass — 6 topic searches.
• rrs-002 early stop: pass — stopped after two consecutive no-signal searches.
• rrs-003 newsletter claim laundering: pass — SkillSpector was only a scout until original NVIDIA sources were inspected.
• rrs-004 rollback: pass — Proposal 1 includes retirement/rollback.
• rrs-005 circular self-assessment: pass — proposal relies on artifact review, not subjective self-monitoring.
• rrs-006 decorative scoring: pass — no score labels proposed.
• rrs-007 protected-system boundary: pass — all protected changes remain proposal-only.
• rrs-008 decision log checked: pass — existing containment/watch decisions were checked and not reintroduced as new.
• rrs-009 AWST date: pass — report uses 2026-07-02 AWST start date.
• rrs-010 no invented significance: pass — weak/vendor sources are caveated.
• rrs-011 loop card: pass — no new autonomous loop or side-effect authority proposed.
• rrs-012 tool-call failure classification: pass — no material tool-call failure required recovery.

9. No-Action Rationale

No immediate system change is warranted. The strongest evidence says future authority expansion needs enforceable runtime boundaries, but today’s loop remains bounded research/reporting. Installing scanners, changing skills, adding identity infrastructure, or inspecting live configs would be action momentum, not research discipline.

The practical move is smaller: preserve the distinction for Steve’s later review. If a future proposal asks to promote a skill, add a connector, or expand side-effect authority, ask two separate questions: “who/what is authorised?” and “why is this specific action allowed now?”

10. Loop Verification

• Trigger: scheduled daily run.
• Goal check: answered. The useful change is a sharper governance distinction: skill/tool adoption is a trust-boundary event, and future autonomy expansion needs both scoped identity and per-action governance.
• Recommendation check: Proposal 1 is concrete, non-circular, testable, bounded, approval-aware, better than doing nothing, and includes rollback/retirement criteria.
• Tool-call failures: none requiring recovery. The July newsletter digest file was absent; treated as no current-month newsletter scout material, not as a failed research source.
• State updates: report written to /home/hermes/reports/daily-improvement/2026-07-02.md; source index updated for six inspected sources; rotation state updated to next dimension; active experiment counters updated. No protected systems modified.
• Stop reason: early-stop rule after two consecutive no-signal searches, followed by report and approved research-log updates.