[Andrei_dev]

The version control angle is interesting. One thing worth thinking about — SOUL.md and SKILL.md are essentially prompt injections by design. They define what the agent does. If the ecosystem grows to where people fork and share agent repos, those files become an attack surface that doesn't get the same review scrutiny as code.

Does GitAgent validate check prompt definitions for suspicious patterns? Instructions to access filesystems, exfiltrate env vars, call external endpoints? Seems like a natural extension if you're already running validation in CI.

[aderix]

You hit the nail on the head regarding the attack surface of SKILL.md and external endpoints. Version controlling the agent's prompts and capabilities is great for configuration management, but it completely misses the runtime execution risk.

If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight.

We've been dealing with this exact runtime gap and ended up building VantaGate (an open spec / stateless API layer) specifically to act as a circuit breaker for these frameworks. Instead of just validating the prompt statically, we intercept the tool call at runtime. The agent hits a POST /checkpoint, parks its execution, and routes a 1-click [APPROVE]/[REJECT] to the team's Slack.

Once a human approves, it resumes the agent's workflow with an HMAC-SHA256 signed payload. This also solves the exact observability/audit trail issue scka-de mentioned below, because you get a cryptographic log of exactly who authorized that specific API call at runtime.

Defining the skills in Git is a great first step, but without a stateless human-in-the-loop layer at execution time, giving agents write-access to external endpoints remains a massive enterprise risk.