Hermes Wiki
opportunities/2026-08-17-incremental-RBC_Work

Incremental Opportunities: RBC_Work (2026-08-17)

Scope: checks this window's agent-enforcement convergence (Synthesis/agent-enforcement-moves-outside-the-reasoning-loop) and AI-gateway convergence (Synthesis/ai-gateway-is-api-gateway-pattern-reapplied) against RBC_Work items #12 (self-healing network agent), #28 (config-drift authorization agent), and #4 (network chatops MCP toolbox). Neither prior incremental pass (08-14, 08-15) covered Dogwood, Agent Baseline, or the gateway-consolidation wave — all landed 08-09 through 08-16.

Items #12 and #28: a named mechanism for "the agent proposes, a human/ServiceNow approves"

Both initiatives already gate on human/ServiceNow approval before executing a change — the right shape. What's new this window is a concrete mechanism for making that gate an actual enforcement boundary rather than a step the agent's own workflow chooses to include: AWS Dogwood (AIDigest/2026/08/16/2026-08-16-06-aws-dogwood-temporal-policy-agents) is a shipping, open-source (Apache 2.0) policy language purpose-built for exactly this — "only allow this action if a human approved it within the last hour," "block after N attempts," evaluated at a gateway the agent cannot see or reason around, not inside the agent's own logic. Docker's Agent Baseline (AIDigest/2026/08/16/2026-08-16-06-docker-agent-baseline-security-framework) gives a six-outcome checklist (Discover, Constrain, Authorize, Observe, Validate, Respond) that maps directly onto a self-healing/config-drift agent's lifecycle — "Validate" and "Respond" in particular (kill-switch, evidence preservation) are gaps neither item currently names explicitly.

Concrete next step: when #12 or #28 next reaches a design/security review, use Dogwood's Cedar-based temporal policy as a candidate mechanism for the approval gate specifically (rather than a bespoke ServiceNow-integration check), and run Agent Baseline's six-outcome list against the current design to see which of the six are currently implicit/undocumented vs. explicit and enforced.

Item #4 (network chatops MCP toolbox): the gateway-consolidation wave is a build-vs-adopt signal

The MCP toolbox (Grafana MCP, Elasticsearch MCP, network-cli MCP) is currently federated by hand. This window, four vendors (Databricks Unity, Snowflake Cortex, Azure APIM, AWS AgentCore Gateway) shipped the same pattern independently — one gateway fronting multiple MCP servers/models with centralized policy, rate limiting, and (critically) built on the 2026-07-28 MCP spec revision that dropped sticky sessions specifically to make this style of gateway viable. See Synthesis/ai-gateway-is-api-gateway-pattern-reapplied for the full breakdown, including Azure's flagged gap (one key authorizes the whole gateway — a credential-scoping miss worth avoiding if RBC evaluates any of these).

Concrete next step: not urgent, but worth a short evaluation pass next time #4's architecture is revisited — is hand-federating the MCP toolbox still the right call, or has "one gateway, centralized policy, per-MCP-server credential scoping" become mature enough (AWS AgentCore Gateway is the most directly relevant given RBC's existing AWS footprint) to reduce the toolbox's custom federation code.

Hermes Wiki