What is the difference between curating AI integrations and isolating agent execution?

Curating integrations is the approval layer. It answers which agents, Skills, MCP servers, and models users are allowed to select. Isolating execution is the containment layer. It limits what a chosen agent can reach and do at runtime. Teams usually need both: curation for governance and usability, isolation for risk reduction and forensic visibility.

What separates approval from containment in agentic AI?

Curating integrations is the control point where a team decides which agents, Skills, MCP servers, and models are allowed into the environment. It is a governance and usability layer. Isolating execution is different: it is the runtime containment layer that constrains what a selected agent can reach, invoke, exfiltrate, or persist once it is running.

The distinction matters because approval reduces what enters the estate, while containment reduces the blast radius after entry. A well-curated catalog can still be dangerous if the runtime is overexposed, and a tightly isolated runtime can still be hard to use if the approved set is poorly chosen.

Why the two controls answer different security questions

Curating integrations asks, “Should this be available at all?” It is about sanctioning the building blocks people can choose, usually through review, policy, and inventory discipline. The control is strongest when the main problem is shadow integrations, inconsistent onboarding, or uncontrolled tool sprawl. Shadow AI and AI Agent Discovery Guide is useful here because discovery and approval are two halves of the same governance problem.

Isolating execution asks, “What can this approved thing do when it runs?” That means limiting network paths, file access, token reach, environment visibility, and cross-workspace movement. In practice, this is where least privilege becomes real. AI Agent Authorisation Guide fits this layer because runtime authorization is what turns broad approval into bounded action.

The two layers also operate at different decision speeds. Curating integrations is usually slower, intentional, and centralized. Isolation needs to be enforced continuously, because the same approved agent can behave very differently across users, projects, or tool chains. When teams treat the catalog as the whole control, they often miss the runtime paths where data leaves the boundary or actions become irreversible.

Where the boundary usually fails

The common failure is assuming that an approved integration is automatically safe to run with production reach. Approval may confirm provenance or business value, but it does not prevent over-broad permissions, implicit trust in connected tools, or abuse of delegated access. That is why containment must sit below the approval process, not inside it.

This is especially important when agents can chain tools, reuse credentials, or call external systems through MCP-style integrations. The risk is not only bad selection, but also good selection with bad runtime scope. Zero Trust for AI Agents supports this separation because verification and least privilege are runtime requirements, not one-time onboarding checks.

Better containment also improves investigation quality. If you can observe the execution boundary, you can tell whether an agent merely had access to a tool or actually used it. That distinction matters for audits, incident review, and proving whether an action was user-driven, policy-driven, or agent-driven. AI Agent Observability, Audit and Incident Response Guide maps directly to that need for attribution and runtime evidence.

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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 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	ASI03 — Identity & Privilege Abuse	Curating and isolating agent access both control agent privilege and delegated authority.
Recommendation — Enforce per-action authorization and limit agent privilege to the minimum required.
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Runtime isolation depends on enforcing what approved agents may reach and do.
	IA-5 — Authenticator Management	Agent integrations often rely on credentials and tokens that must be governed and contained.
Recommendation — Enforce access decisions at execution time, not only during onboarding. Rotate, scope, and revoke credentials used by approved integrations.
NIST Zero Trust (SP 800-207)	AC-1 — Policy and Enforcement Plan	Approval and containment map well to zero trust policy and enforcement separation.
Recommendation — Separate policy decision from enforcement and verify every agent request.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Approved integrations still fail when runtime permissions exceed the task.
Recommendation — Reduce standing permissions and constrain each integration to task-scoped access.

Practitioner Guidance

What to prioritise: Use curation to decide what may exist in the approved catalogue, then use isolation to decide what each selected agent may touch at runtime. If a control only answers one of those questions, it is incomplete for agentic systems.

What to verify: Check that the approved list and the runtime policy are not the same artefact. A team should be able to show separate evidence for integration approval, execution boundaries, and the resulting logs or policy decisions.

Common mistake: Treating a trusted integration as if it were a trusted execution context. Approval reduces choice, but only containment reduces blast radius.

Practitioner takeaway: Good governance decides which agents get a seat at the table; good isolation decides what they can do once they sit down.