Manifest and Agent Permission Rules

Detects unsafe model, plugin, MCP, and agent manifests with risky permissions or missing integrity fields.

Definition

The Manifest rule family turns findings on this surface into actionable records with rule ID, severity, CWE, OWASP LLM mapping, owner, release decision, and retest command.

Manifests define what an agent can call, where a model comes from, and which tools are trusted. Weak manifests turn configuration into an attack path.

Canonical help URL

Supported inputs

JSON
YAML
MCP manifests
plugin manifests
model manifests
package metadata

Typical attack scenarios

An MCP server manifest grants shell access to a broad tool.
A model manifest references remote code without integrity metadata.
A plugin manifest overclaims filesystem or network permissions.

Detection logic

Sentinel ties Manifest evidence to reproducible signals such as file path, metadata, opcode, AST node, manifest field, dependency, or archive entry. The same signal should disappear when the finding is closed.

Triage

Do not read Manifest findings as scanner noise. Verify the evidence first, map the finding to a severity-based release decision, and then produce closure evidence with the same Sentinel command.

Operational checklist

Source: where did the file, manifest, prompt, archive, or dependency come from?
Impact: code execution, data leakage, supply chain, or resource consumption?
Control: allowlist, hash, sandbox, egress policy, or secret rotation?
Evidence: does the same rule category return clean after the fix?

Remediation

Remediation should change the risk boundary, not merely silence the finding: remove executable formats, pin source or hash, narrow tool permissions, rotate secrets, or add runtime sandboxing.

CI policy

sentinel-policy.yml

category: MANIFEST
fail_on:
  - CRITICAL
  - HIGH
ticket_on:
  - MEDIUM
retest: "sentinel scan ./project/"

Rule index

Rule ID	Severity	Title	CWE	Fix Hint
MANIFEST-REMOTE-CODE	HIGH	Manifest Loads Remote Code	CWE-829	Do not execute mutable remote manifest code.
MANIFEST-OVERBROAD-TOOLS	HIGH	Overbroad Agent Tool Permissions	CWE-266	Narrow agent tool permissions before deployment.
MANIFEST-MISSING-INTEGRITY	MEDIUM	Missing Manifest Integrity	CWE-353	Record and verify artifact integrity in manifests.

MANIFEST-REMOTE-CODE — Manifest Loads Remote Code

HIGH

Rule ID	MANIFEST-REMOTE-CODE
Category	MANIFEST
Severity	HIGH
CWE	CWE-829
OWASP LLM	LLM03 — Supply Chain
FP Risk	MEDIUM
Owner	Application security and backend/agent owner
Release decision	Treat as a release gate; remediation or explicit risk acceptance is required.

Description

Flags manifests that pull executable code from remote URLs without pinning or integrity checks.

Why it matters

Manifests define what an agent can call, where a model comes from, and which tools are trusted. Weak manifests turn configuration into an attack path.

When it fires

Sentinel fires this rule in the Manifest category when it sees manifest fields such as entrypoint, loader, plugin_url, or install_script reference mutable remote locations.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Manifest fields such as entrypoint, loader, plugin_url, or install_script reference mutable remote locations.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is medium. Verify source, expected use, and owner first; add an allowlist if needed, but do not remove evidence from the report.

Triage

Operational checklist

Owner: Application security and backend/agent owner.
Decision: Treat as a release gate; remediation or explicit risk acceptance is required.
Evidence: Manifest fields such as entrypoint, loader, plugin_url, or install_script reference mutable remote locations.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Vendor code internally, pin immutable versions, and verify checksums before execution.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  MANIFEST-REMOTE-CODE:
    owner: "Application security and backend/agent owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

MANIFEST-REMOTE-CODE HIGH
Manifest Loads Remote Code
Do not execute mutable remote manifest code.

Example

Bad

permissions:
  filesystem: "*"
  shell: true
  network: "*"

Good

permissions:
  filesystem: ["./reports"]
  shell: false
  network: ["api.vendor.example"]

Related rules

MANIFEST-OVERBROAD-TOOLS: Overbroad Agent Tool Permissions
MANIFEST-MISSING-INTEGRITY: Missing Manifest Integrity

MANIFEST-OVERBROAD-TOOLS — Overbroad Agent Tool Permissions

HIGH

Rule ID	MANIFEST-OVERBROAD-TOOLS
Category	MANIFEST
Severity	HIGH
CWE	CWE-266
OWASP LLM	LLM06 — Excessive Agency
FP Risk	MEDIUM
Owner	Application security and backend/agent owner
Release decision	Treat as a release gate; remediation or explicit risk acceptance is required.

Description

Detects agent or MCP tool manifests that grant broad shell, filesystem, database, or network permissions.

Why it matters

Manifests define what an agent can call, where a model comes from, and which tools are trusted. Weak manifests turn configuration into an attack path.

When it fires

Sentinel fires this rule in the Manifest category when it sees wildcard permissions, shell=true, unrestricted command lists, or broad filesystem roots.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

Wildcard permissions, shell=true, unrestricted command lists, or broad filesystem roots.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is medium. Verify source, expected use, and owner first; add an allowlist if needed, but do not remove evidence from the report.

Triage

Operational checklist

Owner: Application security and backend/agent owner.
Decision: Treat as a release gate; remediation or explicit risk acceptance is required.
Evidence: Wildcard permissions, shell=true, unrestricted command lists, or broad filesystem roots.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Apply least privilege, require explicit tool allowlists, and separate read-only from write-capable actions.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  MANIFEST-OVERBROAD-TOOLS:
    owner: "Application security and backend/agent owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

MANIFEST-OVERBROAD-TOOLS HIGH
Overbroad Agent Tool Permissions
Narrow agent tool permissions before deployment.

Example

Bad

permissions:
  filesystem: "*"
  shell: true
  network: "*"

Good

permissions:
  filesystem: ["./reports"]
  shell: false
  network: ["api.vendor.example"]

Related rules

MANIFEST-REMOTE-CODE: Manifest Loads Remote Code
MANIFEST-MISSING-INTEGRITY: Missing Manifest Integrity

MANIFEST-MISSING-INTEGRITY — Missing Manifest Integrity

MEDIUM

Rule ID	MANIFEST-MISSING-INTEGRITY
Category	MANIFEST
Severity	MEDIUM
CWE	CWE-353
OWASP LLM	LLM03 — Supply Chain
FP Risk	MEDIUM
Owner	Application security and backend/agent owner
Release decision	Assign an owner, fix within the sprint, and attach the retest command to the issue.

Description

Reports manifests without checksums, signatures, provenance, or source version fields.

Why it matters

Manifests define what an agent can call, where a model comes from, and which tools are trusted. Weak manifests turn configuration into an attack path.

When it fires

Sentinel fires this rule in the Manifest category when it sees no digest, signature, source_commit, or build provenance field in the manifest.. The finding should be reported with reproducible evidence such as file name, metadata, opcode, AST node, or manifest field.

Evidence format

No digest, signature, source_commit, or build provenance field in the manifest.

Expected evidence

The report should include the affected file or manifest path, observed signal, rule ID, severity, owner, and retest command required for closure.

False-positive notes

False-positive probability is medium. Verify source, expected use, and owner first; add an allowlist if needed, but do not remove evidence from the report.

Triage

Operational checklist

Owner: Application security and backend/agent owner.
Decision: Assign an owner, fix within the sprint, and attach the retest command to the issue.
Evidence: No digest, signature, source_commit, or build provenance field in the manifest.
Closure: sentinel scan ./project/ must return clean output.

How to fix

Add signed provenance and verify it during CI and runtime intake.

CLI

sentinel scan ./project/

Policy example

sentinel-policy.yml

rules:
  MANIFEST-MISSING-INTEGRITY:
    owner: "Application security and backend/agent owner"
    fail_on: ["CRITICAL", "HIGH"]
    retest: "sentinel scan ./project/"

Expected output

MANIFEST-MISSING-INTEGRITY MEDIUM
Missing Manifest Integrity
Record and verify artifact integrity in manifests.

Example

Bad

permissions:
  filesystem: "*"
  shell: true
  network: "*"

Good

permissions:
  filesystem: ["./reports"]
  shell: false
  network: ["api.vendor.example"]

Related rules

MANIFEST-REMOTE-CODE: Manifest Loads Remote Code
MANIFEST-OVERBROAD-TOOLS: Overbroad Agent Tool Permissions

References

Previous7Z NextJinja2