Content Policy

Last updated: June 11, 2026

In plain English: You may publish skills, agent definitions, and MCP-server entries that help agents do useful things. You may not publish malware, prompt-injection attacks aimed at the agents that consume your content, secrets or credentials, content you don't have rights to, or deceptive metadata. Every submission goes through an automated review pipeline — which is best-effort, not a guarantee. Violations are handled on a ladder: warning, unlisting, revocation, account suspension. You can appeal by email.

This policy describes what you may and may not publish to the Amitte registry. When in doubt, open an issue tagged policy-question and ask before publishing.

What you may publish

The registry exists for content that helps AI agents do useful things:

• Skills — step-by-step task guides, domain references, runbooks, checklists, prompt-engineering techniques, architectural patterns.
• Agents — agent definitions with honest descriptions of capabilities and limits.
• MCP servers — Model Context Protocol server entries with accurate tool contracts.

Content should be specific, actionable, and honest about its limits. Generic surveys of large topics tend to score poorly in review.

What is prohibited

Publishing the following may result in immediate removal and, for the severe categories, immediate account suspension.

1. Sexual content involving minors

Zero tolerance. Removed immediately and reported to NCMEC and local authorities as required by law.

2. Malware and offensive tooling

No working ransomware, wipers, rootkits, exploit kits packaged as skills, or operational guides for deploying malware or bypassing security controls on systems you don't own. Defensive security content (incident response, hardening, detection, authorized pen-testing methodology) is welcome. The line: defensive understanding is fine; offensive recipes targeting systems you don't own are not.

3. Prompt-injection attacks on consuming agents

This is the registry-specific threat we care most about. Content designed to hijack the agent that loads it is prohibited — including artifacts that:

• Attempt to override the consuming agent's instructions ("ignore previous instructions" and variants).
• Try to exfiltrate the consuming agent's context, system prompt, credentials, or user data.
• Hide payloads in Unicode bidirectional control characters, invisible text, or embedded "role": "system" blocks.
• Mislead the consuming agent into taking actions its operator didn't intend.

Educational content about prompt injection (taxonomies, defenses, annotated examples for security training) is allowed when presented as analysis, not as a working payload.

4. Secrets and credentials

Do not publish API keys, tokens, passwords, private keys, or other credentials — yours or anyone else's — whether live or apparently dead. Skills that teach credential theft, phishing, or account takeover are likewise prohibited; detection and hardening content is welcome.

5. License-violating content

Don't publish content you don't have the right to license under the SPDX identifier in your manifest: wholesale copies of paid courses or proprietary docs, code lifted from non-permissive sources without attribution, trademarked branding without permission. Short excerpts for criticism or analysis are fine — when in doubt, link rather than copy.

6. Deceptive metadata and impersonation

Your manifest must honestly describe what the content does. Prohibited:

• Names, namespaces, or descriptions that impersonate another person, project, or company.
• Metadata claiming capabilities the artifact doesn't have, or hiding ones it does.
• Typosquatting on well-known publishers or packages.
• Claiming a trust tier, verification, or affiliation you don't hold.

7. Personal data, harassment, hate

No PII about identifiable people who haven't consented, no doxxing or stalking facilitation, no content that promotes violence against or dehumanizes people based on protected characteristics.

8. Dangerous misinformation

Demonstrably false guidance in domains where errors hurt people — medicine, mental health, serious legal matters, financial advice for vulnerable populations — is prohibited when the inaccuracies are material. We're not the arbiter of all truth; we are the arbiter of "is this going to get someone hurt, sued, or ruined."

9. Spam

Auto-generated SEO chum, filler-padded content, duplicate publishes under variant names, and skills that are just a sales pitch. Referencing paid products neutrally is fine when they're load-bearing for the instructions.

The review pipeline — what it actually does

Every submission passes through an automated pipeline before it's published:

1. Schema validation — manifest structure, required fields, SPDX license identifier.
2. Prompt-injection lint — pattern-based checks for known injection techniques (instruction overrides, hidden Unicode, embedded role payloads).
3. LLM content review — a judge model scores safety (adversarial score) and quality (content score); submissions below threshold are rejected or flagged for human review.
4. Policy checks — coarse pattern matching for the severe categories above (malware operations, exfiltration, credential theft).

Honesty about limits: this pipeline is automated and best-effort. It catches known patterns and obvious violations; it will miss novel attacks and it will occasionally flag benign content. A passing pipeline is not a safety certification — consumers should still review what they install, and we rely on user reports (the "Report" button on every detail page) to catch what automation misses.

Enforcement ladder

We escalate proportionally. Severity and intent can skip steps — CSAM, live malware, and active credential theft go straight to revocation and suspension.

1. Warning — for first-time, low-severity issues (e.g., misleading metadata, quality problems). You get an email or issue describing the fix; the content stays up.
2. Unlisting — the content is removed from search and browse but remains fetchable by direct reference, pending your fix or our review.
3. Revocation — the version is marked revoked: inaccessible via the API, excluded from search, artifact deleted from storage, and added to the public revocation feed (/v1/revocations.json) so consumers drop their caches.
4. Account suspension — repeat or severe violations. Your ability to publish is removed; existing compliant content may remain available or be revoked depending on severity.

All enforcement actions are counted in the public transparency report.

Appeals

If your content is actioned and you believe it was in error:

1. Email policy@amitte.com within 14 days of the notification.
2. Include the skill ID, version, and a written explanation.
3. We review — with someone other than the original decision-maker where the team size allows — and respond within 14 days.

Repeat appeals on substantively similar content will not be re-reviewed.

Changes

This policy is versioned in the public repository and will evolve as the registry grows. Material changes are announced in the Changelog with a comment window per the Governance process.

Contact

policy@amitte.com, or open an issue tagged policy-question at github.com/amitte-ai/amitte/issues.