$CHARON is live on @bankrbot
CA: 0x5efe15c1783a5fe04ed289f3760e03afe3d6bba3
we put a ton of effort into shipping the MVP and have been building for the last two weeks.
for the MVP, we integrated codex since it runs locally.
next is @aeonframework, which runs on github actions and needs an aeon-native hook/adapter.
we are already in contact with @aaronjmars.
we launched the token on bankr to support development, inference costs, and bring more attention to what we are building.
$CHARON skill pack is now live on @aeonframework.
it ships two skills:
- `charon-setup` installs and verifies enforcement
- `charon-policy` lets users manage policy through natural language
install the pack, define your policy or keep the default, and keep using AEON normally.
PASS โ continue
PAUSE โ ask for approval
DENY โ stop before launch
โ https://t.co/a0KWzgTYGn
thanks @aaronjmars for merging ๐ซก
looking into b20 rn.
base is shipping tokens with a much richer control surface than normal erc20s, and most people will not know what they are actually touching.
might build something for that.
Everything that can be breached will be breached we are in control the blast radius stage now. We cannot stop penetration, but can prevent sensitive actions from happening in case your agent gets hacked.
Everything that can be breached will be breached we are in control the blast radius stage now. We cannot stop penetration, but can prevent sensitive actions from happening in case your agent gets hacked.
Major tech companies are working on agent policy enforcement, but most implementations are still inaccessible to everyday users ๐
- @Microsoft
https://t.co/xRmB9mKEoh
- @awscloud
https://t.co/nJo3LNX2Gt
- @googlecloud
https://t.co/r4uexxgMGV
We also love what @ATBASHai is building, although it is not publicly available yet.
$CHARON is a firewall for AI agents.
Security and privacy were optional in the early internet. Everyone thought they were unnecessary until something broke.
The same pattern is repeating with AI.
We are giving agents access to code, files, wallets, APIs, browsers, and production systems. Some users do not even know what their agents execute behind the scenes.
We call this autonomy: an agent executing human intent.
But what happens when it does the opposite?
A bad prompt, malicious context, or simple misunderstanding can leak secrets, delete files, publish code, move assets, or trigger irreversible actions.
Prompts cannot enforce prompts.
Charon checks actions before execution:
agent action โ policy โ PASS / PAUSE / DENY โ execution โ receipt
This architecture has been researched across major security and cloud teams. Until now, implementing it required experienced security engineers and custom infrastructure.
Our first priority is enforcement.
Our second is making that enforcement accessible to everyone.
Security should be invisible, not annoying.
Install the Charon skills, define a policy with your agent or keep the default, and continue using your agent normally.
(Figure: @Microsoft Security Blog)
this is really cool ๐ค
fleet watcher is (the already existing) self-hosted ALLOW/BLOCK gate wired into @aeonframework actions: before each skill run it asks your control plane "is this allowed?" - BLOCK means Claude never runs (and it fails closed if unreachable), then a postflight step logs the outcome for taint analysis. you define red lines centrally in its dashboard (per-skill caps, allowlists, dangerous-string patterns), making it good for governing many instances at once.
@Charon_AI built a cool additive solution that adds a local policy layer at the same chokepoint: policy lives in the repo (charon.aeon.yml) instead of a hosted server, and it introduces a middle verdict - PASS / PAUSE / DENY - where PAUSE routes to Telegram for human approval instead of a hard allow/block.
so fleet watcher gives you centralized external red lines across the fleet, while charon gives you repo-local, reviewable rules with a human-in-the-loop step and signed receipts.
this is really cool ๐ค
fleet watcher is (the already existing) self-hosted ALLOW/BLOCK gate wired into @aeonframework actions: before each skill run it asks your control plane "is this allowed?" - BLOCK means Claude never runs (and it fails closed if unreachable), then a postflight step logs the outcome for taint analysis. you define red lines centrally in its dashboard (per-skill caps, allowlists, dangerous-string patterns), making it good for governing many instances at once.
@Charon_AI built a cool additive solution that adds a local policy layer at the same chokepoint: policy lives in the repo (charon.aeon.yml) instead of a hosted server, and it introduces a middle verdict - PASS / PAUSE / DENY - where PAUSE routes to Telegram for human approval instead of a hard allow/block.
so fleet watcher gives you centralized external red lines across the fleet, while charon gives you repo-local, reviewable rules with a human-in-the-loop step and signed receipts.
We are actively testing Charon inside @aeonframework's GitHub Actions workflow.
Hereโs what we shipped yesterday ๐
- Charon preflight for AEON workflows
- policy-based PASS / PAUSE / DENY before the agent run starts
- signed receipts for every AEON preflight decision
- review queue for paused actions
- GitHub Actions summary export for reviewable runs
- TG decision bridge groundwork
- public AEON test repo with real PASS / PAUSE / DENY runs: https://t.co/dsK7yhhFtx (watch us testing live)
Charon turns the AEON workflow trigger into a typed action before Claude starts: skill, input, actor, repo, trigger, and run id go into policy; the workflow only continues if the verdict is PASS.
Next, weโre wiring TG notifications:
- DENY โ user gets notified that the task was blocked
- PAUSE โ user gets an approval request before execution continues
Itโs coming sooner than you think.
We tested @base MCP with an unlimited USDC Permit2 approval request.
The request never reached Base Account.
Interlock: an MCP control plane for runtime enforcement.
๐งต