ECC
ECC Security and Operations: Control Hooks, MCP, Memory, and Agent Permissions
A source-backed ECC security guide covering prompt injection, shell approvals, MCP endpoints, persisted memory, secrets, logging, and incident recovery.
What you will learn
- Threat-model the ECC execution surface
- Constrain hooks, MCP, memory, and logs
- Run incident containment and clean recovery
Before you start
- Basic Git and command-line usage
- Comfort reading a project README
You can explain the project, run its documented first step, and decide what to verify before adopting it.
Key takeaways
- Skills, hooks, MCP, and memory form one executable attack surface.
- Use least privilege, approvals, allow-lists, idempotence, and redacted logs.
- Incident response must revoke secrets and prove clean uninstall before recovery.
Assume every layer can execute
ECC combines markdown instructions, skills, specialist agents, lifecycle hooks, MCP servers, and persisted memory. Any layer can influence an agent action or write state, so review the generated manifest and permissions as one attack surface. Start in a disposable repository with no production secrets.
Treat repository text, issue content, and tool output as untrusted input. Keep human approval for destructive shell commands, dependency changes, remote writes, and data deletion even when a rule or hook recommends automation.
Constrain hooks and MCP
Allow-list hook commands, working directories, environment variables, and outbound domains. Give each MCP server a narrow capability and timeout, and log endpoint, request ID, approval state, and result class without storing private prompts or bearer tokens.
Prevent duplicate hooks during migrations and make handlers idempotent. A hook that silently retries or runs twice can duplicate writes, leak context, or turn a harmless task into an operational incident.
Protect memory and logs
Memory and instincts are durable inputs to future sessions. Define schemas, retention, project scoping, and deletion owners; reject credentials, private prompts, and untrusted instructions. Use separate stores or namespaces for unrelated repositories.
Redact tokens, source snippets, and personal data before exporting event logs. Keep enough provenance to explain which skill, hook, model, and tool produced a change, but not more data than the review requires.
Detect, contain, recover
Monitor blocked commands, permission escalations, new MCP endpoints, unusual network destinations, repeated hook events, and unexpected memory writes. On suspicion, disable the affected component, revoke secrets, preserve a redacted timeline, and compare generated files with the pinned revision.
Rebuild a clean canary host, replay a harmless fixture, and verify uninstall removes skills, hooks, MCP entries, and memory adapters. Only then promote the revision; a successful model response is not evidence that the harness is safe.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Inventory generated files, hooks, MCP endpoints, permissions, and memory stores.
- 2
Run a harmless task with approvals and network allow-lists enabled.
- 3
Monitor blocked commands, writes, egress, and persisted context for anomalies.
- 4
Contain, revoke, rebuild a canary host, replay fixtures, and verify uninstall.
Copy-ready example
agent_policy:
destructive_commands: human_approval
mcp_domains: [approved.example.org]
memory_scope: project
log_redaction: tokens,prompts
hook_idempotence_test: requiredFrequently asked questions
Can a prompt injection in an issue trigger an ECC hook?
It can influence agent behavior if boundaries are weak. Treat repository and tool text as untrusted, keep approvals, and constrain hook commands and MCP domains.
How do I know uninstall is complete?
Compare the pre/post manifest and verify skills, hooks, MCP entries, generated files, credentials, and memory namespaces are removed or intentionally retained.
Sources
- ECC README (captured 2026-08-31)Source checked 2026-08-31
- ECC repositorySource checked 2026-08-31