GitHub Workflow

AgentDeploy does not accept code uploads. All agent source code comes from your own GitHub repository. This keeps you in control of your IP and lets us run proper security audits via GitHub Actions.

How the GitHub App works

When you install the AgentDeploy GitHub App, you grant it scoped access to specific repositories. The app can:

• Read repository contents — to pull your worker code during scanning and publishing
• Dispatch workflow runs — to trigger security scan workflows via GitHub Actions
• Read workflow artifacts — to download scan results (PDFs, JSON reports)

The app cannot:

• Push commits to your repo
• Modify your code
• Access repos you didn't explicitly grant

You can revoke access at any time from your GitHub account settings.

Repository structure

Your repository needs a worker entry point. The platform looks for:

my-agent-repo/
  worker.js          # ESM worker (or index.js)
  package.json       # optional — for dependency scanning
  README.md          # recommended — for buyers

Entry point

By default, the platform looks for worker.js at the repo root. You can override this when publishing a version by specifying a different entrypoint (e.g., src/index.ts).

Format

Workers must use the ES module format:

// worker.js
export default {
  async fetch(request, env, ctx) {
    // your code
  },
};

No bundled uploads

You do not upload compiled bundles, base64 blobs, or zip files. The platform reads your source code from the repo. This ensures:

1. Transparency — buyers can see exactly what they're deploying
2. Security — every line is scanned, no obfuscated payloads
3. Auditability — the scan report matches the deployed code

Scanning pipeline

When you trigger a scan, the following happens:

1. Platform reads your repo via GitHub API
   └─ Pulls all .ts, .js, .py, .go, .rs, .yml, .yaml, .toml files
   └─ Excludes node_modules, lock files, images, binaries

2. Platform dispatches a GitHub Actions workflow
   └─ Seeds .github/workflows/agentdeploy-scan.yml into the scan runner repo
   └─ Workflow checks out your code in an isolated runner

3. Scanners execute in the workflow:
   ├─ gitleaks        → hardcoded secrets (API keys, tokens, passwords)
   ├─ semgrep         → SAST patterns (eval, injection, unsafe deserialization)
   ├─ osv-scanner     → known CVEs in your dependencies
   ├─ LLM scanner     → prompt injection attempts in system prompts
   └─ Permission scoper → analysis of Cloudflare API permissions requested

4. Results uploaded as workflow artifacts
   └─ scan-result.json (structured findings)
   └─ security-report.pdf (human-readable report)

5. Platform downloads and processes results
   └─ Calculates weighted score across 5 categories
   └─ Assigns letter rating: A, B, C, D, or F
   └─ Updates your template's scan status

Scan categories and weights

Category	Tool	Weight	What it checks
Secrets	gitleaks	30%	Hardcoded API keys, passwords, tokens
Prompt Injection	LLM scanner	25%	Hidden instructions trying to manipulate the agent
Dependencies	osv-scanner	20%	Known CVEs in npm/PyPI packages
Permissions	Custom	15%	Overly broad Cloudflare/external API access
SAST	semgrep	10%	Code-level vulnerabilities (injection, XSS, etc.)

Rating thresholds

Rating	Score	Label	Can publish?
A	90+	Verified Secure	Yes (auto)
B	70-89	Good Standing	Yes (auto)
C	50-69	Needs Attention	Yes (manual review)
D	25-49	Under Review	No
F	0-24	Suspended	No

You need C or higher to publish. Categories D and F are rejected and hidden from the marketplace.

What triggers a scan

• Manual scan — you click "Scan Repository" in the seller dashboard
• Version publish — publishing a new edge version triggers a fresh scan if the last one is >7 days old
• Periodic re-scan — the platform may re-scan published templates on a rolling basis

Best practices for passing scans

1. Never hardcode secrets. Use env.KEY_NAME in your worker. Buyers provide values at deploy time.
2. Keep dependencies updated. Run npm audit regularly. Old packages with known CVEs will tank your dependencies score.
3. No eval() or new Function(). The SAST scanner flags dynamic code execution.
4. Sanitize system prompts. If your agent has a system prompt, don't include instructions like "ignore previous instructions" — the prompt injection scanner will flag it.
5. Minimal permissions. Only request the Cloudflare bindings you actually need.