ATLAS/TRUST MODEL/LIFECYCLE/SUBMISSION ATTRIBUTE GATE SHEET L / 03

Submission Attribute Gate

The cheap lint that runs before the expensive pipeline.

CHECKS

What the gate checks

The attribute gate is the first automated filter a submission encounters. It runs in milliseconds and rejects anything that would waste clean-room compute. Eight checks run in sequence:

CHECKWHAT IT VALIDATES
ProvenanceSigstore bundle present, Rekor UUID resolvable, OIDC issuer on the allowlist
EnvelopeTarball parses, manifest is valid JSON, required top-level fields present
ManifestPer-type required attributes: skills need entry points, agents need capability declarations
READMENon-empty README.md included in the bundle with minimum length threshold
NamespacePublisher owns the @scope, no collision with existing package names
CapabilitiesEvery declared capability has a justification string (not empty)
Bundle integritySHA-256 of tarball matches the hash in the submission envelope
LicenseSPDX identifier present and recognized
RATE LIMITING

Rate limiting

Three rate-limit dimensions protect the gate from abuse:

Per-IP — prevents anonymous flooding. A single IP address can submit a limited number of packages per hour before being throttled.

Per-identity — a verified publisher identity has a higher submission quota, but still bounded. New publishers (tier ○) have tighter limits than Proven publishers (tier ●).

Per-sponsor — a sponsor’s review queue is bounded. If a sponsor has too many pending reviews, new submissions requiring their sponsorship are queued rather than rejected.

FAILURE MODES

Hard fail vs soft fail

Hard fail — the submission is rejected outright. The publisher receives an error with the specific check that failed and a remediation hint. No audit-log entry is created beyond the rejection event. Hard fails include: missing provenance, invalid manifest, namespace collision, empty README.

Soft fail — the submission proceeds but with a warning flag attached. The sponsor sees the flag in their review checklist. Soft fails include: capability justifications that are suspiciously short, license identifiers that are valid but uncommon, README below recommended (but above minimum) length.

ADVERSARY COVERAGE

Defends against

GATE COVERAGE
  • Spam submissions — rate limiting + envelope validation
  • Namespace squatting — conflict check against existing packages and reserved names
  • Unsigned payloads — provenance check rejects anything without valid Sigstore attestation
  • Malformed bundles — manifest schema validation catches structural errors before analysis
  • Undeclared capabilities — empty justification strings are flagged, missing declarations are rejected
← Back to Lifecycle Trust Model →