What
While reading through platform/governance.py, hooks.py, mcp_cron.py, and sel.py closely, I found two real gaps between what the governance model promises and what it currently delivers under specific conditions.
- Cron jobs are only governance-vetted once, at
cron_add authoring time. If a policy gets tightened after a job is already scheduled, that job keeps running under the old rules until someone notices and manually re-authors it. This is actually documented in the maintainers' own comments in mcp_cron.py, but it isn't fixed.
- The SEL audit log's HMAC signing key lives in the same trust-root directory as the log it protects. That makes it tamper-evident against partial or accidental edits, but not against a fully compromised host or an admin-level actor, who could rewrite the log and re-sign a clean-looking chain.
verify_integrity() would report success either way.
Alongside fixing those two, I'd like to propose two smaller, related pieces:
- A reference
security_policy.json built on the existing network.egress scope, so operators have a starting point for a residency-aware egress allowlist. Config only, no engine changes.
- Docs (and maybe a small CLI surface) making the two enforcement tiers that already exist explicit: the blocking governance gate versus the advisory auto-approve config in
config.json. Conflating those two is an easy mistake for anyone building on top of KiroCrew, since only one of them actually blocks.
To be clear about scope: this isn't about model routing or inference region. I looked into that first and #1693 already covers the real gap there (agent.provider is fixed to acp, no pluggable routing today). That's a different problem owned by kiro-cli, not KiroCrew. This issue is scoped to what KiroCrew's own governance layer can actually enforce: tool calls, shell commands, file paths, and with these changes, cron re-validation and audit log integrity.
Why
This maps directly to two of the project's own tenets: "every action is gated, auditable, and reversible where it can be, and where it cannot be you are asked first" (#1) and "sensitive information must never spread" (#6). Right now there are two concrete places where that promise has a gap. A tightened policy doesn't reach already-scheduled cron jobs, and the audit trail can be quietly rewritten by anyone with host-admin access without the integrity check catching it.
Neither of these is a vulnerability in the SECURITY.md sense, nothing is currently being bypassed that shouldn't be. They're both real, honest gaps between the model's promise and its current guarantees under those two conditions, and I'd rather close them properly than leave them as known-but-undocumented tradeoffs.
Additional context
Happy to scope this as a few independent, smaller PRs instead of one big change:
- Re-run governance validation at cron execution time, not just authoring time. Small, contained change to
mcp_cron.py / cron_script.py.
- The reference
security_policy.json, shipped as an example/doc, not a new default.
- An external checkpoint mechanism for the SEL hash chain. This one probably needs an RFC first since it changes the audit log's trust model.
- Docs and CLI work to make the two enforcement tiers explicit.
Wanted to open this and get a read on the approach before putting real time into any of it, per the contributing guide. Also curious if any of this overlaps with something already in flight that I missed.
What
While reading through
platform/governance.py,hooks.py,mcp_cron.py, andsel.pyclosely, I found two real gaps between what the governance model promises and what it currently delivers under specific conditions.cron_addauthoring time. If a policy gets tightened after a job is already scheduled, that job keeps running under the old rules until someone notices and manually re-authors it. This is actually documented in the maintainers' own comments inmcp_cron.py, but it isn't fixed.verify_integrity()would report success either way.Alongside fixing those two, I'd like to propose two smaller, related pieces:
security_policy.jsonbuilt on the existingnetwork.egressscope, so operators have a starting point for a residency-aware egress allowlist. Config only, no engine changes.config.json. Conflating those two is an easy mistake for anyone building on top of KiroCrew, since only one of them actually blocks.To be clear about scope: this isn't about model routing or inference region. I looked into that first and #1693 already covers the real gap there (
agent.provideris fixed toacp, no pluggable routing today). That's a different problem owned by kiro-cli, not KiroCrew. This issue is scoped to what KiroCrew's own governance layer can actually enforce: tool calls, shell commands, file paths, and with these changes, cron re-validation and audit log integrity.Why
This maps directly to two of the project's own tenets: "every action is gated, auditable, and reversible where it can be, and where it cannot be you are asked first" (#1) and "sensitive information must never spread" (#6). Right now there are two concrete places where that promise has a gap. A tightened policy doesn't reach already-scheduled cron jobs, and the audit trail can be quietly rewritten by anyone with host-admin access without the integrity check catching it.
Neither of these is a vulnerability in the SECURITY.md sense, nothing is currently being bypassed that shouldn't be. They're both real, honest gaps between the model's promise and its current guarantees under those two conditions, and I'd rather close them properly than leave them as known-but-undocumented tradeoffs.
Additional context
Happy to scope this as a few independent, smaller PRs instead of one big change:
mcp_cron.py/cron_script.py.security_policy.json, shipped as an example/doc, not a new default.Wanted to open this and get a read on the approach before putting real time into any of it, per the contributing guide. Also curious if any of this overlaps with something already in flight that I missed.