That’s a sharp observation.
You’re partially right CAP (our protocol) handles the structural canonicalization. We use strict Protobuf/Schematic definitions, so if an agent sends a messy JSON that doesn't fit the schema, it’s rejected at the gateway. We don't deal with 'raw text' tool calls in the backend.
But you are touching on the semantic aliasing problem (e.g. rm -rf vs rm -r -f), which is a layer deeper.
Right now, we rely on the specific Worker to normalize those arguments before they hit the policy check, but having a universal 'Canonical Action Representation' upstream would be cleaner.
If you can turn 'messy intent' into a 'deterministic hash' before it hits the Cordum Scheduler, that would be a killer combo. Do you have a repo/docs for CAR yet?
Exordex is a great tool for the CI/CD pipeline to test agents. Cordum is the Runtime Kernel that enforces those policies in production. Ideally? You use Exordex to test that your agent works, and Cordum to guarantee it stays safe.
Great question. This is actually a core design principle of the Cordum Agent Protocol (CAP).
It’s definitely a *structured rejection*, not a silent fail.
Since the LLM needs to "know" it was blocked to adjust its plan, the kernel returns a standard error payload (e.g., `PolicyViolationError`) with context.
The flow looks like this:
1. *Agent:* Sends intent "Delete production DB".
2. *Kernel:* Checks policy -> DENY.
3. *Kernel:* Returns a structured result: `{ "status": "blocked", "reason": "destructive_action_limit", "message": "Deletion requires human approval" }`.
4. *Agent (LLM):* Receives this as an observation.
5. *Agent (Re-planning):* "Oh, I can't delete it. I will generate a slack message to the admin asking for approval instead."
This feedback loop turns safety from a "blocker" into a constraint that the agent can reason around, which is critical for autonomous recovery.
It is overkill for a demo. But for my production environment, I need an external safety layer. I can't rely on 'prompt engineering' when real data is at stake.