A job manifest is the human-owned specification that defines what an agent run is allowed to do. It names the owner, authoritative sources, required checks, permitted actions, and actions that can never be earned. In practice, it turns vague intent into an enforceable control boundary before execution begins.
Expanded Definition
A job manifest is the execution contract for an agent run. It translates intent into an authorised boundary by naming the owner, stating the authoritative sources the agent may consult, defining required checks, listing permitted actions, and marking actions that are permanently out of scope. In NHI governance, that distinction matters because an agent with tool access can act, but only the manifest should say what it is allowed to do under a given run.
Definitions vary across vendors, but the practical pattern aligns with control-bound execution and Zero Trust thinking: every task should be explicit, bounded, and reviewable before the agent starts. That is why practitioners often map manifest design to principles reflected in the NIST Cybersecurity Framework 2.0, even when no single standard governs job manifests yet.
The most common misapplication is treating a job manifest as a suggestion or prompt wrapper, which occurs when the agent can silently expand scope beyond the declared owner, sources, and permitted actions.
Examples and Use Cases
Implementing job manifests rigorously often introduces more upfront specification work, requiring organisations to weigh operational speed against predictable and auditable agent behaviour.
- An agent is allowed to reconcile SaaS user records only from approved HR and identity sources, with a manifest that forbids direct writes to production directories.
- A code-remediation agent may open pull requests, but the manifest requires static analysis, human approval, and a read-only source-of-truth path before merge.
- A finance workflow agent can extract invoices and classify payments, while the manifest blocks outbound email, token creation, and any credential export.
- An incident-response agent is permitted to collect logs from named systems and run predefined containment checks, but cannot disable accounts unless that action is explicitly earned by policy.
- For broader NHI governance context, the Ultimate Guide to NHIs is useful when comparing manifest design to credential lifecycle controls and privilege boundaries.
These patterns become more reliable when paired with identity and access policy, rather than embedded only in prompts, and they resemble the enforcement mindset described in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
A job manifest reduces the chance that an autonomous agent inherits more power than the task requires. Without it, tool access, secrets, and context can blur together, and a simple workflow agent can become a high-impact identity with unrestricted reach. That matters in NHI environments because 97% of NHIs carry excessive privileges, and job manifests are one of the clearest ways to prevent that condition from being repeated at run time. NHI Mgmt Group also reports that only 5.7% of organisations have full visibility into their service accounts, which shows how often execution controls are missing even before an agent is introduced.
Manifests also support auditability. When an action is challenged, defenders can compare what the agent did against what the manifest authorised, rather than reconstructing intent from logs alone. That makes them valuable for governance, incident response, and offboarding. The same logic appears in the Ultimate Guide to NHIs, where visibility, privilege control, and lifecycle management are treated as linked problems rather than separate ones.
Organisations typically encounter manifest gaps only after an agent overreaches, at which point job manifest controls become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Job manifests constrain agent autonomy, execution scope, and tool use. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Manifests reduce excessive privilege and unsanctioned use of secrets by agents. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and enforced for each agent operation. |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero Trust limits must be explicit and continuous for machine actions. |
| CSA MAESTRO | MAESTRO covers governed agent execution and policy-bounded autonomy. |
Define each agent run with explicit allowed actions, sources, and hard stops before execution.
Related resources from NHI Mgmt Group
- How should organisations manage access reviews for changing job roles?
- What is the difference between workload automation and job scheduling for IAM teams?
- What breaks when a build job has more access than the policy change itself requires?
- What breaks when Kubernetes manifest rendering trusts user input?
