This plan explains how the Agentic Enterprise Readiness Profile handles security for an independent OSS profile repository.
It is written for maintainers, external reviewers, and AAIF/LF-style community reviewers who need to understand the security boundary before trying the profile against a real repository.
This document is not a certification, audit report, AAIF endorsement, Linux Foundation endorsement, or production-readiness claim.
The repository currently contains:
- Markdown documentation
- JSON schema
- JSON examples
- boundary-model examples
- issue templates
- a lightweight local validation script
The repository does not currently operate:
- a hosted service
- a database
- an authentication system
- a payment flow
- a model provider integration
- a queue, worker, or background runtime
- a production data store
Security risk is therefore concentrated in contributor behavior, documentation hygiene, schema integrity, release discipline, and supply-chain hygiene.
Security reporting follows SECURITY.md.
Use GitHub issues for non-sensitive security concerns such as missing guardrails, unclear secret-safety guidance, broken validation assumptions, or overly broad claims.
Do not open a public issue that includes:
- credentials
- customer data
- private vulnerability details
- screenshots containing tokens
- proprietary internal architecture
- exploit instructions that materially increase risk
If sensitive detail is required, contact the maintainer privately first and only publish a sanitized public follow-up after the sensitive material is removed.
Contributors must not commit real secrets, private customer evidence, private policy documents, or screenshots containing tokens.
Examples and templates must use:
- placeholder values
- environment-variable names
- secret-reference names
- redacted excerpts
- synthetic data
The profile should describe required secret boundaries without asking contributors to expose the actual secret values used by their own systems.
The repository is intentionally small and has no runtime service dependencies.
Current supply-chain controls:
- dependency and license posture is documented in
docs/DEPENDENCY_LICENSE_INVENTORY.md - validation runs through the repository's GitHub Actions workflow
- examples are checked against
schema/agentic-readiness.schema.json - release notes state what changed and which checks ran
- no vendored third-party code is expected in docs, examples, or templates
Before a release, maintainers should recheck:
npm testgit diff --check- package metadata parsing
- changed documentation for accidental secrets
- changed examples against the JSON schema
This project should adopt external security hygiene signals in stages instead of claiming maturity too early.
Planned checks:
| Stage | Action | Evidence target |
|---|---|---|
| 1 | Keep SECURITY.md, this posture plan, dependency inventory, release checklist, and validation workflow current. |
Public docs and passing validation workflow. |
| 2 | Enable OpenSSF Scorecard or an equivalent public security-health workflow once the repository shape stabilizes. | Public workflow result or issue explaining blocked checks. |
| 3 | Review OpenSSF Best Practices criteria and document which items apply to a documentation/profile repository. | Public gap issue or checklist. |
| 4 | Consider branch protection, signed releases, and stricter workflow permissions if external contributors or adopters increase. | Repository settings evidence where public, or maintainer note where settings are private. |
Until these checks are actually enabled and passing, the project must describe them as planned, not complete.
Every release should answer:
- Did validation pass?
- Did docs or examples introduce any real secrets?
- Did dependency or license posture change?
- Did the release checklist run?
- Did the release notes avoid endorsement or production-readiness claims?
- Did any security-relevant issue remain open, and is it documented?
Security-sensitive releases should prefer smaller changes and clearer evidence over large bundled edits.
Maintainers should keep public review focused on concrete artifacts.
Good issues and PRs:
- identify one repository boundary, schema field, validator behavior, or documentation gap
- avoid private screenshots or internal customer names
- include a local proof path
- state whether the evidence is static inspection, local validation, or live runtime proof
- avoid promotional language
Poor issues and PRs:
- ask maintainers to review private data in public
- claim AAIF, Linux Foundation, enterprise, or production status without evidence
- add paid-service defaults without OSS alternatives
- add broad marketing copy without improving repository safety or usability
AI-assisted contributions are allowed when they are reviewed by a human maintainer before merge.
AI tools must not be used to:
- paste private secrets into prompts or issues
- infer unsupported production-readiness claims
- auto-post outreach at scale
- open noisy PRs across many repositories
- replace maintainer judgment on security-sensitive changes
Contributors should disclose AI assistance when it materially shaped a contribution and should keep the proof path reproducible by humans.
Release notes should link to:
- the release tag
- the validation workflow run
- the changed public docs
- the issue or PR when the release responds to external feedback
This keeps the project reviewable without relying on private chat logs or unpublished claims.
This posture supports public review and responsible OSS contribution. It does not create:
- AAIF affiliation
- Linux Foundation affiliation
- OpenSSF certification
- SOC 2, ISO, or enterprise security certification
- production-readiness proof
Those claims require separate formal processes and independent evidence.