One agent definition. Every harness. Governance is the part we still need to build.
Asterism deploys one governed agent — persona, skills, permissions, MCP wiring — into Claude Code and the OpenAI Codex CLI, translating your permission model into each harness’s own enforcement primitive. That part is built and verified. Policy enforcement, approval gating, and audit are not, and we are looking for one design partner to build them against a real policy.
What does work today
One thing on this page is built, runtime-verified, and not something a single-vendor console does. It is the reason a governance layer on top is worth building at all.
You define an agent once — persona, skills, permissions, MCP wiring — and aster deploy materializes it into each harness’s own native config. The permission model is translated into whatever that harness actually enforces with:
- fs:read becomes sandbox_mode = "read-only" in Codex's config.toml
- autonomy:suggest becomes approval_policy = "on-request"
- The same model becomes deny: ["Bash","WebFetch","Write","Edit"] in Claude Code's .claude/settings.json
Claude Code and the OpenAI Codex CLI are verified against live installs. OpenClaw, Hermes, and Eve adapters are validated against documentation only and ship as beta — Eve silently drops the permission model entirely. That is the honest state of it.
Read this before you read the rest.
Asterism today does not enforce skill policies, does not gate installs on approval, and does not write an audit record when an agent is deployed. What ships today is the registry, the security scanner, the CLI, and agent deploy into Claude Code and the OpenAI Codex CLI. Everything on this page marked “Planned” is a design we are looking for a first design partner to build against.
Centralized control over AI skills
None of the following is enforced today. This is the shape of the layer we want to build: define who can use what, gate installs on approval, and keep a durable record of every install and deploy.
Skill Policies
Planned: define whitelist or blacklist policies per organization so an install of a disallowed skill fails at the CLI.
- Whitelist mode: only approved skills
- Blacklist mode: block specific skills
- Per-org policy configuration
- Category-level controls
Approval Workflows
Planned: route a new skill through your review process before it reaches developers, with a hard gate on install.
- Pending → Approved → Active flow
- Multi-reviewer support
- Expiration policies
- Decision history
Audit Logging
Planned: a durable record of who installed or deployed what, when, and into which harness — exportable for review.
- Install and deploy events
- Skill lifecycle events
- API access tracking
- Export for review
Organization Management
Partly built: organizations, members, roles, and namespaces exist today. Policy enforcement on top of them does not.
- Role-based access control
- Multiple namespaces
- Member invitation flow
What the registry checks before a skill ships
Two checks run at publish time. Both are static checks on skill content — they do not sandbox or supervise a skill once your harness loads it.
Security Scanning
Every skill scored 0-100 before publishing. Regex and pattern matching for secrets, code execution, file system access, credentials, network, and system calls.
- 6 pattern categories
- Auto-reject below 50
- Critical: -25, High: -15, Medium: -10
Typosquatting Protection
Blocks skill names that mimic existing ones. Levenshtein distance, character substitution, and a reserved names list, checked at publish time.
- Name similarity detection
- Reserved names list
- Character substitution checks
Things you may have read about that do not run
These appear in our repository and our older docs. They are libraries and pages with no call site, so treat them as unbuilt.
- Provenance & similarityA similarity comparison and a provenance table exist in the codebase, but nothing in the publish path calls them and no provenance record is ever written.
- DMCA & copy reportingHandled by a human over email, not in the product. There is no takedown intake form, no counter-notice workflow, and no copy-reporting flow. A general report-abuse button files into a moderation queue.
- Author reputationReputation scoring exists as a library. It is not computed on publish and is not shown on author profiles. Creator verification badges do render.
Compliance
Asterism holds no security or compliance certifications. There is no SOC 2 report, no ISO 27001 certificate, and no HIPAA attestation. If your procurement process needs one, we are not ready for you yet — tell us which one and when, and we will say honestly whether we can get there.
Want this built? Help us build it.
We are looking for one design partner who actually has this problem, so the enforcement layer gets built against a real policy rather than an imagined one. No plan, no price, no SLA to quote yet.
Or skip the form and email enterprise@joinasterism.com.