[longtermop]

This is great — manifest validation feels like the right “static” layer for the agentic web.

One nuance: a lot of prompt-injection / tool-abuse issues happen at runtime, when the agent is consuming untrusted content coming through perfectly “valid” channels (web pages, emails, tool outputs, even responses from allowed domains).

So I like to think: manifests cover the what (permissions / declared capabilities), but you also need something that covers the when — runtime content scanning + policy enforcement before that content is allowed to influence tool calls or sensitive actions.

Curious if you’ve thought about pairing this with runtime guardrails (e.g., classify/strip instructions in fetched content, detect credential exfil patterns, etc.)?

[benjifisher]

Spot on. I see UCP manifests as the "Trust Contract" that defines what is possible, but you're right—contract fulfillment in a non-deterministic environment is where things get messy.

My goal with UCP Checker is to solve the first-order problem: "Is this even a valid endpoint?" You're describing the critical second-order problem: preventing an agent from being hijacked via Indirect Prompt Injection once it actually fetches that content.

I’ve been thinking about this separation of concerns a lot. Ideally, we need a layered approach:

Static Layer (UCP Checker): Validates the schema, capabilities, and reachability.

Runtime Layer: A proxy or sidecar that scans fetched content for "ignore previous instructions" patterns or credential exfiltration attempts before the LLM processes it.

I’d love to hear if you think that "Runtime Guardrail" should live on the merchant side (e.g., a "UCP Shield" gateway) or if it's strictly the responsibility of the Agent/Model provider to sanitize inputs?