Repository audit · research date 25 Sep 2026
Marketing Agent OS: provenance and host-harness boundary audit.
Marketing Agent OS is a library of marketing skills and related materials. It is not, on the checked evidence, a marketing application, credential store, scheduler, approval system, or agent runtime.
What is in the repository
Documented fact. The repository describes a cross-platform library of marketing-oriented Agent Skills. Its root lists skills, agents, assets, documentation, memory, references, schemas, scripts, tests, tools, tracked upstream snapshots, installer wrappers, notices, and hash material. The root LICENSE is Apache-2.0 text, while the README limits that statement to the wrapper and normalized layer.
Provenance boundary
The checked source manifest names four upstream snapshots and pinned commits. The architecture says those snapshots are not installed and that selected skills are projected into a target harness directory.
Do not overstate the licence
NOTICE identifies one Apache-2.0 upstream and three MIT upstreams. This audit did not compare every retained file with each upstream commit or verify every retained notice.
Documentation inconsistency. The README says 236 uniquely named installable skills. The architecture and compatibility material say 235. Both are project statements. Treat neither as a current inventory guarantee until the catalogue and intended install output are reviewed.
Installation creates a host-owned file change
| Route | What the checked material establishes | What remains unverified here |
|---|---|---|
| Agent Skills CLI | The README documents npx skills add and selection prompts. | Conflict, update, and copied-file behavior of that separate CLI. |
| Shell / PowerShell wrappers | install.sh and install.ps1 delegate to the Python installer. | All file effects beyond that delegation. |
| Python installer | Architecture describes selected-skill projection, staging, atomic replacement, and exclusion of upstreams/. README says --force replaces a same-name skill. | Exact copied members, permissions, collision handling, backups, rollback retention, and every error path. |
| Local Claude marketplace | INSTALL documents a local marketplace route. | Its resulting file effects and update behavior. |
Compatibility documentation names harness-specific project and user destinations. Those paths show where an installer intends to write; they do not prove that a target harness discovers, obeys, or permission-gates a skill.
The library does not establish host controls
| Capability | Result of this audit |
|---|---|
| Model calls, scheduling, durable state, runtime logging | Not documented as a library runtime capability in the checked material. |
| Credentials and connectors | Security policy says optional connectors may need separate credentials and inherit provider and host-harness security. Exact implementations, scopes, storage, and calls were not established. |
| Filesystem and subprocesses | The wrappers invoke Python. The documented installer needs target-directory writes. Exact helper-by-helper side effects were not inventoried. |
| Approvals and account mutation | The policy says authorization is needed before external or persistent actions. No technical approval engine, sandbox, credential vault, network allowlist, or immutable action log was established. |
Inference. This is a reusable instruction and skill library for an independently selected host environment. The host and operator decide tool access, network access, credentials, filesystem rights, review, logs, retention, and recovery.
Maintenance and security signals are limited
The checked main-history page showed eight visible commits; the tip was dated 4 September 2026. SECURITY.md describes a private GitHub vulnerability-reporting route and says fixes apply to the latest release on main. The visible release surface did not independently establish a release/tag for its stated supported 1.1.x line. These are process and activity signals, not proof of reliability, support quality, security, or a reproducible release.
The README claims tests, three-OS validation, doctor results, and GitHub Actions. This audit did not run tests or inspect CI results, artifacts, signatures, branch protection, or full helper sources. A hash manifest is an integrity record, not an independently verified supply-chain attestation.
Bounded decision
Use only for local, reviewable planning work in an approved harness.
Best fit: a developer or consultant who already operates a permissioned coding-agent harness and wants a small set of marketing-planning instructions. It is not a CRM, sender, scheduler, credential store, or autonomous publisher on this evidence.
- First evaluation
- Use an empty non-client repository, fictional facts, selected skills, no secrets, and no configured connectors.
- Stop point
- One local draft and file-diff review; then remove the scratch files.
- Do not do
- No sends, posts, CRM changes, paid-media actions, credentials, live data, public webhooks, scheduling, or account mutation.
Open evidence before broader use: exact normalized-skill derivation and retained notices; installer collision and rollback behavior; helper side effects; connector scopes; release artifacts; reproducible CI results; and a selected-host smoke test in an isolated environment.
Primary sources checked
- Repository overview / README
- Main commit history and checked tip commit
- LICENSE, NOTICE, and source manifest
- Architecture, INSTALL, and compatibility matrix
- SECURITY and hash manifest
This report does not give legal advice or a production recommendation.