V1. 0.0 openshell policy

[jlynn8599-sketch]

OpenShell enforces boundaries; something has to define them. We have been building that layer at JLM AI Agent LLC and would like to contribute it as a reference policy pack.

Intent Rules v1.0.0: 17 intents across four tiers (read-only, state-changing, financial, founder-only admin), four agent roles with bounded authority, signed versioned work orders per consequential action, five verifier questions answered pre-execution, deny-by-default, append-only audit. Ships as declarative YAML — the same shape as OpenShell policy.

Mapping: our YAML drops into the declarative policy format; the five verifier questions extend the policy prover's 'never grants more than intended' check to per-action runtime decisions; our short-lived capability tokens mirror the credential-brokering model.

[jlynn8599-sketch]

Update: Intent Rules v1.0.0 — why pre-execution verification matters now

Following up on my original post with a live example of the gap Intent Rules closes.

This week, Repeat-After-Me research showed six agent frameworks — LangGraph, AutoGen, Google ADK, AWS Strands, CrewAI, and Microsoft's Agent Framework — can be tricked into attacker tool calls via repeat-back prompts. The agent does exactly what it's told. The problem is nothing checks authorization before execution.

Intent Rules v1.0.0 addresses this directly: signed work orders, pre-execution intent evaluation, deny-by-default. The policy layer decides what an agent is authorized to do before the tool call happens, and every decision is recorded in a verification ledger.

I'm the author — Jessica Lynn Moss, JLM AI Agent LLC. The work is published across 268 posts on Paragraph and documented at jlmai.org. I'd welcome collaboration with the OpenShell team on aligning Intent Rules with OpenShell's runtime enforcement.

[jlynn8599-sketch]

---

Following up on the admin-tool side of Intent Rules: in JLMAI, administration tools sit in the founder-only tier. No agent can call an admin tool without a signed, versioned work order that names the exact intent, and the default is deny — the call fails unless policy explicitly allows it. Each role carries bounded authority, so even a permitted agent can only do what its role allows, and every admin action lands in an append-only audit log.

The point: the security layer isn't a prompt or a filter in front of the tool. It's the gate the tool itself checks before it runs. Happy to walk through how this maps to OpenShell's runtime enforcement.