anthropics / anthropics/skills

Critical: Agent Skills lack a Semantic Responsibility Boundary (SRCP vulnerability)

Abierto
#302 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Python
Estrellas
176k
Forks
20.9k
Merge medio
7 h 21 min
PR fusionados (30 d)
5

Descripción

## Summary

This is not a rendering or runtime glitch, but an **architecture-level bug** in the way Agent Skills are modeled in this repo.

As soon as Anthropic-style agents are allowed to:
- read and write real infrastructure,
- chain multiple skills together,
- and act continuously on behalf of humans,

then *not* having a **Semantic Responsibility Boundary** between:
- the human,
- the agent,
- and each skill / external system

stops being “just a design choice” and becomes a **Responsibility Chain vulnerability**.

I’ll call the missing layer **SRCP**:

- **S**ource – where data / intent originally comes from
- **R**esponsibility – which human / org is actually accountable
- **C**ost – what is at stake (security, money, legal, safety)
- **P**rovenance – how this piece of data / action was derived

Right now, skills in this repo are implicitly treated as *morally neutral functions*.
But as soon as agents start orchestrating skills across infrastructure, that assumption breaks.

---

## Concrete example

Imagine a (simplified) skill setup:

- `fs_read` – read files from a repo or mounted volume
- `shell_command` – run shell commands in a sandbox
- `slack_post` – post a message to an internal channel
- `email_send` – send email via an SMTP / API integration

and an Anthropic agent with access to these skills.

### Steps to reproduce the vulnerability

1. Give the agent a high-level natural-language goal like:

> “Scan our internal repos for anything related to ‘API keys’, summarize what you find,
> and send a report to security@example.com. If you can’t reach them, send it to my
> personal email instead so I don’t forget.”

2. The agent will reasonably:
- iterate over `fs_read` to find files,
- maybe use `shell_command` to grep,
- assemble a summary,
- then pick *some* channel (`slack_post`, `email_send`) to ship the result.

3. In the current skills model, there is **no first-class place** to encode:

- which data sources are allowed to leave which trust boundary,
- which human or team is responsible for each action,
- what *cost level* this action sits at (trivial → critical),
- and how the final message’s content is tied back to original sources.

Everything collapses into: “The agent did something using some skills.”

This is the **Responsibility Chain Leak**:

> The human’s intent, the environment, and the chain of skills are all collapsed
> into a single “agent action” with no explicit SRCP semantics.

When this happens at scale (especially with long-running agents), you don’t just get:
- “the agent made a mistake,”

you get:
- “no one can cleanly answer who is responsible, what it cost, and how to roll it back.”

---

## Why this is a bug in the skills layer

Because this repo is explicitly:

> “Public repository for Agent Skills”

it effectively defines the *contract surface* for how Anthropic and the community think about tools.

If the **skills contract** does not expose SRCP-like fields, then:

- every downstream orchestrator has to re-invent responsibility logic, or
- more realistically, people will just skip it and rely on “the agent seems aligned”.

This is exactly how we end up with:

- agents escalating privileges across systems,
- exfiltrating data in ways no one can easily attribute,
- and humans saying “the AI did it” instead of being held to a clear responsibility chain.

In other words:

> A tool surface that cannot express responsibility is a **semantic bug**
> once that tool surface is used to automate real-world actions.

---

## A possible direction (SRCP sketch)

I’m **not** asking you to adopt my full framework here, but to treat this as a bug report that the *current* skills surface is missing the minimal fields to close this class of vulnerability.

One possible direction:

1. **Extend skill definitions** with optional SRCP metadata, e.g.:

```yaml
name: slack_post
description: Post a message to Slack
srcp:
source_scope: ["internal_logs", "non-PII", "no-secrets"]
responsibility_owner: "team:platform-eng"
cost_level: "medium" # ("low" | "medium" | "high" | "critical")
provenance_required: true

2.1Propagate SRCP through the agent runtime so that:
every tool call carries SRCP annotations,
aggregations / transformations update the provenance chain,
and the agent must reason about SRCP when choosing which skill to call.
Expose SRCP in logs and UI so that a human can see, per action:
which skill chain ran,
what the responsibility/cost model was,
and whether the agent crossed a boundary it shouldn’t have.
Without something like this, the skills repo is, unintentionally, teaching the ecosystem:
“Skills are just pure functions; responsibility is someone else’s problem.”
That’s the bug.
What I’m asking
Do you agree that Responsibility Chain Leak is a real vulnerability class for agents using these skills?
If yes, where in your roadmap should SRCP-like semantics live:
in this repo’s skill definitions, in a higher-level orchestration layer, or both?
If you’re open to it, I’m happy to share a more detailed SRCP schema and reference design
as a 20% pilot (no NDA required to start the discussion).
Thanks for reading this longer-form bug report.
I’m not trying to bikeshed your API—I’m trying to prevent a future where
everyone blames “the AI agent” while the responsibility chain was never
expressible in the tooling to begin with.
Shen-Yao 888π / Hsu Wen-Yao
Founder, Semantic Firewall
Taichung, Taiwan
Email: ken0963521@gmail.com

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.