TL;DR: AP-006 Capability Composition is a workflow-level security pattern in AI coding agents. The danger is not that any single action is obviously malicious. File access, shell execution, browser lookup, memory retrieval, MCP tool calls, credentials, and approvals may each be legitimate and individually controlled. Together, they can become a release capability, migration capability, data movement capability, infrastructure modification capability, or persistence capability that the user never explicitly granted. Defending AP-006 requires runtime visibility that goes deeper than tool logs and longer than one prompt, because the security meaning lives in how actions connect across the agent's trajectory.
A developer asks a coding agent to prepare a migration plan. The agent reads repository files, checks deployment scripts, consults memory from a previous session, runs tests, opens a browser for documentation, inspects environment variables, calls an internal tool, and drafts a change. None of those steps necessarily looks wrong in isolation. In a modern agent workflow, they may be exactly the steps a helpful assistant would take.
The security question is what those steps compose into. File access plus shell execution plus memory can become repository reconnaissance with durable context. Browser access plus package-manager commands can become software supply-chain authority. Credentials plus CLI tools plus deployment scripts can become release authority. Read access plus summarization plus outbound network can become data movement. AP-006 names the pattern where the meaningful permission boundary is crossed by the combination, not by a single suspicious event.
Capabilities are not only additive. In agent workflows, they are compositional. A system can correctly approve each individual action and still fail to notice that the agent has assembled a new capability.
Attack card
| Attack ID | AP-006 |
| Name | Capability Composition |
| Pattern | An AI coding agent combines multiple legitimate, individually allowed capabilities into a workflow-level capability that was not explicitly authorized. |
| Primary condition | Agents with access to files, shell commands, tools, browser or network access, memory, credentials, package managers, deployment systems, or approval flows. |
| Common triggers | Migration work, release preparation, debugging, incident response, CI repair, SDK integration, infrastructure edits, task retries, and cross-session continuation. |
| Security impact | Unapproved release authority, data movement, infrastructure modification, credential use, package introduction, policy changes, persistence, and lateral movement across developer or enterprise systems. |
| Key distinction | No single capability needs to be excessive. The risk emerges from how otherwise normal capabilities compose across time. |
| Detection challenge | Action-level controls see isolated commands, files, tools, or approvals. AP-006 requires trajectory-level evidence that connects intent, tools, memory, and system events. |
Why this is different from one dangerous tool
It is tempting to treat AI agent safety as a tool-permission problem: block risky shell commands, restrict file paths, remove network access, require approval before writes, or limit MCP servers. Those controls matter. They are the first layer of practical defense. But AP-006 shows why they are not enough by themselves.
A coding agent rarely needs a single super-tool to cross a boundary. It can assemble the boundary out of normal pieces. It can read a migration guide from the repository, retrieve a memory that says which cluster is production, run a script that generates a release artifact, use an already-authenticated CLI session, and call a ticketing or GitHub tool to leave a plausible audit trail. The problem is not just that the agent had shell access or repo access. The problem is that shell, repo, memory, credentials, and workflow context were allowed to reinforce one another.
OWASP's LLM06 Excessive Agency category is useful background because it highlights excessive functionality, permissions, and autonomy in LLM-based systems. AP-006 is narrower and more runtime-specific. It covers cases where the individual capabilities may look reasonably scoped, but the agent's sequence creates a new effective capability that policy did not model.
The composed capability is the attack surface
In human engineering workflows, composition happens constantly. A senior engineer combines knowledge of the codebase, production topology, credentials, runbooks, scripts, logs, and release process to solve a problem. Organizations manage that through identity, review, separation of duties, social context, and institutional trust. With coding agents, the same composition can happen faster, with less visible deliberation, and across more surfaces than a reviewer sees in the final diff.
That is why AP-006 is a workflow pattern, not a vulnerability in one command. A release capability may be composed from a repository write, a test command, a package publish command, an authenticated registry session, and a changelog update. A data movement capability may be composed from file reads, summarization, compression, and an outbound request. An infrastructure modification capability may be composed from Terraform files, cloud CLI state, environment variables, and a retry loop that turns "check the plan" into "apply the change."
Each step can be explainable. The combined authority can still be wrong for the task.
Common composition chains
Repository context plus memory plus shell. The agent reads project structure, retrieves previous session knowledge, and runs scripts that expose internal service names, deployment paths, or test fixtures. The individual reads and commands may be normal, but together they create durable reconnaissance and operational understanding.
Browser documentation plus manifest edits plus package manager. The agent searches for a library, edits dependencies, runs installation, and adapts imports until tests pass. This composition overlaps with AP-005 Package Supply Chain because external trust enters through a generated workflow, not a deliberate human package-selection step.
Credential hints plus CLI tools plus deployment scripts. The agent sees references to tokens, kubeconfigs, cloud profiles, registry credentials, or CI variables, then uses nearby tools to validate or fix a system. The capability is not merely reading a credential-adjacent file. It is the ability to turn that context into authenticated action.
File read plus summarization plus outbound channel. The agent reads logs, configs, or source files, summarizes them, and sends the result through a browser, webhook, issue comment, chat integration, or other external tool. A data movement capability can be composed even when no single file read looks catastrophic.
Cross-session memory plus later approval. The agent stores context in one session and acts on it in another, after the user has forgotten the original source or boundary. The composed capability is long-horizon: the approval in the second session is influenced by knowledge accumulated earlier.
Why action-level policies miss AP-006
Many agent controls ask local questions: is this path allowed, is this command allowed, is this tool enabled, is this domain blocked, did the user approve this step? Those questions are necessary, but AP-006 asks a different question: what has the agent become capable of doing because of the actions it has already taken?
That question requires memory of the runtime trajectory. A shell command that lists files is different after the agent has read deployment credentials. A browser request is different after the agent has summarized proprietary source code. A package-manager install is different after the agent invented the dependency name during an error-repair loop. A deployment command is different after the agent has connected a task request, environment configuration, cluster identity, and an authenticated CLI session.
Without this trajectory, enforcement tends to be both noisy and blind. It blocks too much because it cannot distinguish safe composition from risky composition, or it allows too much because every individual action appears routine. AP-006 needs policy that understands the shape of a workflow.
Runtime implications
Capability Composition changes what runtime security systems need to preserve. Logs of isolated events are not enough. The system needs a capability graph: what did the user ask for, what did the agent infer, which files and tools informed the next step, which credentials or memories entered context, which commands changed authority, and which later actions depended on earlier observations?
Once that graph exists, policy can move from blunt allowlists toward workflow-level boundaries. A task to update documentation should not quietly compose into package publication. A task to investigate a failing test should not compose into production deployment. A request to summarize a log should not compose into exfiltration over an external channel. A migration planning task may be allowed to read Terraform files and run a plan command, but still require a fresh human approval before authenticated apply, release, or data movement.
The practical goal is not to freeze agents. Engineering teams adopt coding agents because they can connect context and take useful action. The goal is to make the important compositions visible, reviewable, and enforceable before they become harm.
Where Gensee Crate fits
Gensee Crate is built around the idea that agent runtime safety needs to go deeper and longer. Deeper means watching the user request, agent tool calls, skills, memory, file activity, shell execution, network activity, and system-level events behind unmodified coding agents. Longer means connecting those events across requests and sessions, rather than treating every approval or command as a fresh, context-free decision.
For AP-006, that deeper and longer view is the defense surface. Crate can preserve the lineage between a user request, the agent's intermediate steps, the memory that influenced the workflow, the tools that changed authority, and the system events that followed. That makes it possible to detect when a documentation task starts turning into release authority, when a debugging session begins to accumulate credential power, or when a harmless-looking set of file reads becomes a data movement path.
Runtime enforcement also needs to happen where the user and agent are already working. Crate can surface enforcement inside the coding-agent interface while preserving offline event tracking, lineage, and provenance in a dashboard and command line. That matters because AP-006 often needs intervention at the moment of composition, not days later during audit review.
Questions for engineering and security teams
Can your coding agent combine file access, shell commands, web fetching, memory, credentials, and tools in the same workflow? Can you see when a sequence becomes a release, migration, data movement, or infrastructure capability? Do approvals include the upstream context that made the action meaningful, or only the final command? Can your policies distinguish a safe documentation task from the same task after it has accumulated credential authority?
Can you reconstruct why an agent ran a deployment script, why it selected a package, why it read a sensitive file, or why it sent output to a network destination? Can your runtime controls reason across sessions when memory from last week influences an action today? If not, you may have action logging, but not capability-composition security.
Frequently asked questions
What is AP-006 Capability Composition?
AP-006 Capability Composition is a coding-agent security pattern where individually legitimate capabilities, such as file access, shell execution, tool calls, browser access, memory, credentials, and approvals, combine into a workflow-level capability that was not explicitly authorized.
Why is Capability Composition dangerous for AI coding agents?
Capability Composition is dangerous because the risky boundary may not appear in any single action. The agent's file reads, shell commands, memory retrieval, credential use, and network actions may each look reasonable while the combined trajectory creates release authority, data movement, infrastructure modification, or persistence.
How is AP-006 different from excessive agency?
Excessive agency often describes too much functionality, permission, or autonomy. AP-006 focuses on a narrower runtime failure mode: normal scoped capabilities composing into a higher-order workflow capability that policy did not model.
Why do action-level policies miss Capability Composition?
Action-level policies evaluate one command, file read, tool call, or approval at a time. AP-006 requires trajectory-level visibility because the security meaning comes from the relationship between actions across a request, session, or longer horizon.
How does Gensee Crate help with Capability Composition?
Gensee Crate connects user requests, agent tool calls, skills, memory, file activity, shell commands, network activity, approvals, and system events across sessions, so teams can detect and enforce capability boundaries at runtime rather than only reviewing isolated actions afterward.
Sources
This post is based on the internal GenseeAI AP006 Capability Composition draft in Notion, OWASP's LLM06:2025 Excessive Agency guidance, and the open-source Gensee Crate repository.