Supervisor middleware

[pimlock]

Summary

Supervisor middleware is OpenShell's data-plane extensibility mechanism. It lets operators extend supervisor-managed data paths with trusted components that can inspect, transform, block, or annotate operations at defined hooks.

This parent issue tracks the supervisor middleware capability as a whole. Individual hook families, deployment models, security boundaries, and operational improvements are tracked as focused subissues.

Status

The initial supervisor middleware implementation landed in #2010 through PR #2027. It introduced the first hook for outbound HTTP requests before credential injection, with built-in and operator-run middleware support.

Further capabilities are tracked independently rather than as sequential implementation phases.

References

• Design: RFC 0009 in rfc/0009-supervisor-middleware/
• Initial implementation: feat: implement initial supervisor middleware #2010
• Extensibility roadmap: OpenShell Extensibility #1904

[jhjaggars]

I opened an issue with a similar goal the other day: #1694
In my case the middleware needs to execute after credential injection.

[pimlock]

@jhjaggars

I opened an issue with a similar goal the other day: #1694 In my case the middleware needs to execute after credential injection.

I saw the issue come in as I was working on this and realized that the initial shape didn't solve this, as it's assuming a single pre-credential injection hook.

My initial thought was to add a post-credential hook, but limit it to be available to built-in middleware only, so the user-provided middleware couldn't hook into there, but a first-party sigv4 one could. We could remove this limitation somewhere down the road if needed, e.g. once we support deploying middlewares in a controlled environment.

I still need few hours to get the proposal to a reviewable state, so that part around first and third party middlewares is not yet fleshed out.

[pimlock]

@jhjaggars thanks again for bringing this up, I added a comment in your original issue: #1694 (comment)

Please let me know if you have any questions/concerns/feedback!

[eeee2345]

Landed here from #1272 (thanks @johntmyers for the redirect). One concrete data point for the "trusted middleware / guard service" shape in the egress hook:

We maintain ATR (Agent Threat Rules, MIT) — an open detection-rule standard for agent traffic (prompt injection, tool poisoning, context/credential exfiltration, MCP attacks), Sigma/YARA-style content rules. It's a natural fit for the egress-inspection stage you describe: given outbound request content, return allow / block / annotate plus the matched rule IDs, with no model call (pure rule eval), so it stays cheap enough to run inline before forwarding.

If helpful for the v1 hook design, I can prototype an ATR-backed egress guard against whatever interface signature you land on, as a reference implementation of the "guard service" role. Keeping it to the design here rather than re-opening #1272.