This is a proposed architecture for discussion and implementation planning. It is not deployed security infrastructure, a compatible product specification or a claim that every agent platform exposes these controls. The implementation must be tested in the intended environment.
1 · Inventory and admission
The registry stores the capability identifier, publisher, exact revision, dependency manifest, owner, data classes and requested access. A reviewer examines the package and its installation behavior. The admission record describes permitted tasks, explicit exclusions and review expiry. Store the evidence with a change history, and ensure the running revision can be matched to the reviewed revision.
2 · Identity and authorization
The invoking user, agent workload and downstream service may need separate identities. Bind authorization to the intended resource and action. Validate both tool selection and arguments, including destination, project and object identifiers. Scope minimization and token audience checks are central themes in the official MCP guidance. [Source 1]
3 · Isolated execution
Run executable components with limited filesystem and network access. Give temporary working directories only the data required for the task. Define whether child processes, package installation and outbound downloads are allowed. Test which restrictions actually propagate to those child processes. Isolation limits consequences; it does not make every allowed operation acceptable. [Source 4]
4 · Decision points for external effects
Distinguish reading, drafting, staging and completing an action. A request to prepare an email does not imply sending it, and a preview is not a published change. Approval records should identify the concrete destination, content and effect. Ensure the approved object is the same one ultimately transmitted, so a later modification cannot silently inherit earlier approval.
5 · Logging and revocation
Log decisions with enough context to investigate without retaining unnecessary secrets. Provide controls to disable the capability, revoke its credential and stop active execution. Test revocation instead of assuming it works from a dashboard status. Determine how caches, queued jobs, open sessions and downloaded artifacts behave after access is withdrawn.
A practical procurement packet
Request the supported platform and version, architecture diagram, permission model, authentication design, update mechanism, dependency evidence, logging fields, data destinations, incident process and independent testing scope. Ask the supplier to demonstrate least-privilege operation and revocation with a representative task. Keep unanswered questions visible in the procurement decision.