Nine of you left one comment each over the last 7 weeks. Rather than post 9 separate response articles, here's a batched reply. Each section links back to your original comment.
@bogumi_jankiewicz (gate.cat) — Jul 27
"Drift detection answers 'did the skill change?' — but blast radius is decided at a much narrower interface: the concrete action that reaches the shell/API."
Right distinction. L3 (drift detection) answers "did the artifact change since attestation." gate.cat answers "is this specific call about to do something outside policy." They compose — L3 catches supply-chain drift, gate.cat catches runtime blast radius. The 0.6% intervention rate on 1M+ real commands is a useful real-world data point; much higher than I'd have guessed.
I read your bypass map at https://github.com/BGMLAI/gate.cat — the "deny-gate is certain only about what it blocks, an unmatched action is unchecked, not safe" framing is the honest version most enforcement layers skip. The L3 + exec-boundary split is the right architecture; I should have framed L3 as the supply-chain side, not the innermost layer.
@reneza — Jul 23
"The piece that closes it is a runtime interception layer, a hook that sees each tool call the installed skill actually makes and checks it against a policy before it runs."
Your gist (https://gist.github.com/renezander030/a6761638d44a08748cfb45cd61bfa6e4) is basically what I should have built first instead of stacking more import-time YARA families. The post-exec filter is in the repo: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/uta-monorepo/packages/gateway/src/post-exec-filter.ts — runs after each tool call (not before, like your hook). Pre-call allow/deny (your version) + post-result filter (mine) compose: pre-call answers "is this call allowed right now," post-call answers "did this call's result exfiltrate anything."
If you want to PR your pre-call hook as a layer in addition to the post-exec filter, the file to add it to is uta-monorepo/packages/gateway/src/pre-exec-filter.ts.
@mayank609 (Failproof AI) — Jul 21
"We're building Failproof AI. Our focus is on runtime reliability and policy enforcement."
Complementary, not competing. ATC/1.0 is the credential format (signed, verifiable, revocable). Failproof AI is the runtime enforcement layer that consumes the credential and decides per-call whether to allow/deny. If you want to talk about how ATC could be the input format for Failproof AI's runtime policy engine, email info@alicelabs.site. Spec: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/marketnow/docs/atc-spec/SPEC.md
@jkming — Jul 18
"Have you considered what happens if the CA key itself is compromised? Would love to see a follow-up on key rotation and multi-sig for high-value agents."
CA key compromise is the worst case. The keypair is generated offline, private key in YubiHSM, rotation via a key registry signed with an offline root key. The registry contains ca_key_id, ca_public_key, previous_ca_key_id (for grace period), rotation_epoch, issued_at/expires_at (short max-age), and root_signature from the offline root.
Multi-sig for high-value agents is spec'd but not yet implemented — attestation.signature becomes an array of {signer_ca_id, signer_ca_public_key, signature} and the verifier requires N-of-M. The test vectors at https://github.com/alicelabs-llc/universal-trust-adapter/tree/main/marketnow/docs/atc-spec/test-vectors cover the single-sig case for now.
@nazar-boyko — Jul 16
"Signatures catch the cheap 90%, but the next one won't match a known family — so '0 in quarantine' reads as '0 skills tripped my static rules,' not '0 malicious skills.'"
That's the honest tension. L3 (Semgrep) and L4 (YARA family signatures) are exactly the shape of defense that missed the first trojan until we'd seen it. The fix isn't more static rules — it's the post-exec filter for runtime behavior + the prompt-injection corpus for measurable detection quality. The corpus is at https://github.com/alicelabs-llc/universal-trust-adapter/tree/main/uta-monorepo/packages/gateway/src/vectors/prompt-injection-corpus
@alexshev — Jul 16 and Jul 5
"A marketplace has too many trust surfaces for one big check to mean much: package identity, permissions, runtime behavior, update path, and user intent all need different evidence."
Agreed. The ATC spec splits it more honestly than the 8-layers article did:
- ATC-003 Capabilities → permissions
- ATC-004 Evidence → package identity + runtime behavior
- ATC-007 Revocation → update path
- ATC-008 Expiration → time window
-
risk.decision_authority: "consumer"→ user intent (still the consumer's call)
Spec: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/marketnow/docs/atc-spec/SPEC.md
On the "downloads are vanity" point from your other comment — agreed. Install observability is in marketnow-install-stack@1.1.0: after install, posts a signed receipt with install_id (random UUID, no PII), package_version, install_status, first_tool_call_result. No user-identifying data, but lets us see the funnel from install → first successful tool call → 7-day retention.
@kordless — Jul 13
"ACP is a spec for agent to agent comms: agentclientprotocol.com/get-started/introduction. Your stuff is interesting though, but it's more than a protocol."
You were right — I should have known about ACP before naming my protocol "ACP." What I built is more accurately a trust credential format (ATC/1.0) plus a verification protocol, closer to X.509 + OCSP than to ACP. Renamed to UTA (Universal Trust Adapter) — it translates between trust credential formats (ATC, EAT-AI, ZTA, A2A, MCP Card, W3C VC) via a canonical Universal Trust Schema.
ACP defines how agents talk to each other; ATC/1.0 defines how agents prove who they are. Complementary, not competing.
@pakvothe — Jul 7
"Los objetos TRANSLATIONS a mano funcionan hasta que el producto empieza a cambiar seguido, ahí cada string nuevo son 5 ediciones y algo siempre queda atrás."
Tienes razón. Para MarketNow terminamos con un híbrido: strings estáticos del marketplace en objetos JSON versionados con el repo (pocos, cambian poco), strings dinámicos (descripciones de skills, mensajes de audit) servidos vía API para que un cambio no requiera redeploy. i1n.ai se ve útil para proyectos más en el lado "mucho string, mucho cambio" del espectro — gracias por la recomendación.
@custralis — Jul 2
"Worth pairing it with --read-only rootfs + explicit tmpfs, --cap-drop ALL, --security-opt no-new-privileges, a non-root USER, and memory/pids limits so a runaway tool can't fork-bomb the host."
All of those are now in the sandbox config we ship:
docker run --rm -i \
--network none \
--read-only \
--tmpfs /tmp:rw,size=64m,mode=1777 \
--cap-drop ALL \
--security-opt no-new-privileges \
--user 65534:65534 \
--memory 256m \
--pids-limit 64 \
--cgroup-parent=/marketnow/audit \
"$IMAGE"
Full config in the repo: https://github.com/alicelabs-llc/universal-trust-adapter/blob/main/uta-monorepo/packages/gateway/Dockerfile. For servers that genuinely need outbound calls, separate egress-proxy container with allowlist + per-call logging, same as you described.
— Edison
Top comments (0)