AID-H-004.006: Hosted Agent Publication & Exposure Controls

Version 1.20261015 · Actionable sub-technique

Prevent unintended access to agents published through vendor-hosted and low-code platforms. The tenant platform administrator and agent release owner enforce approved audiences, channels, sharing boundaries, and connector execution identities before publication and after configuration changes.

Applies to organizations publishing agents on shared provider infrastructure, including provider-owned hostnames; merely consuming a vendor assistant is outside this control. Shipping tenant data policies, channel restrictions, and agent administration interfaces provide the implementation path. Public agents are allowed only through a versioned exception whose reachable knowledge, tools, and identities are appropriate for anonymous users.

Evidence combines effective tenant and agent configuration, complete published-agent inventory, denied publication attempts, and independent access probes against the published version. No applicable hosted agents means NOT_APPLICABLE; incomplete inventory or unavailable effective permissions means INSUFFICIENT_DATA, collection failure means ERROR, and reachable unauthorized capabilities mean FAIL. PASS requires both preventive settings and successful negative access tests for the applicable population. This publication gate also covers the release of provider-native event-trigger configurations. Where the hosted platform has no tenant-controlled pre-run admission point, verify the native trigger filters, approved event resources and dedicated execution identity here; a configured maker connection does not prove per-event initiator authorization. Missing supplier evidence remains INSUFFICIENT_DATA, and an unenforceable required restriction prevents release.

Pillars: app, infra

Lifecycle: building, validation, operation

Scope boundary

Owns the technical release and configuration-drift gate for hosted agents: who can reach each published agent and which channels, shared connections, and knowledge sources that audience can exercise.

AID-M-001.005: Discovery supplies the hosted-tenant population and exposure findings; this control configures and verifies the publication restrictions.

AID-H-004.002: Reuse workload authentication; a service identity alone does not establish the audience of a published SaaS agent.

AID-H-004.007: Event-to-run authority is checked at trigger admission; publication approval does not authorize each external event.

AID-H-018.002: Runtime per-action authorization remains independent of the publication gate.

AID-I-003: Containment owns disabling access after a finding; this control owns release denial and exposure configuration.

Implementation guidance

AID-H-004.006-G001

Enforce tenant and environment publication restrictions, with bounded exceptions for intentionally public agents.
Step 1: Establish the release boundary

Use the tenant administration plane, not a prompt instruction, to control who can create environments, publish agents, change authentication, share with the entire tenant, and enable channels. Separate public-agent environments from internal-agent environments. Bind an approved release record to tenant ID, environment ID, agent ID, published version, channel set, audience, knowledge-source IDs, connector operation IDs, connection identities, and policy version. Store it in an administrator-controlled repository; a maker cannot approve their own exception by setting a field on the agent.

Step 2: Configure a concrete hosted-platform path

In Microsoft Power Platform admin center, apply data policies to every relevant environment, including newly created environments. For internal agents, block the connector Chat without Microsoft Entra ID authentication in Copilot Studio. Restrict unneeded channel connectors, including Direct Line where custom websites, the demo website, or mobile channels are not approved. In Copilot Studio, verify the published agent authentication and sharing settings. The default authentication choice is not proof that makers cannot change it. Restrict environment creation and maker/security roles through the platform administration settings, then attempt publication with a disallowed channel and with authentication disabled using a test maker account. Both must fail. Follow the platform data-policy instructions and record the applied policy IDs and effective environment coverage.

For a deliberately public FAQ, use a separate, approved environment with public-only knowledge and narrowly scoped operations. An exception must expire under release policy and match the exact deployed agent/version; it is not a tenant-wide permission to publish anonymously. Retest access after sharing, connector, channel, or knowledge changes. If a platform cannot enforce the required restriction, keep the affected release blocked or move that workload to an enforceable deployment path.

AID-H-004.006-G002

Verify effective connector and trigger identities before exposing a hosted agent to its approved audience.
Step 1: Resolve the identity actually used

For every reachable connector, action, knowledge source, and event trigger, read back the effective connection provider and account from the published configuration. Compare the account's actual resource permissions with the audience and task boundary. A maker-owned connection may authorize more than the caller. Do not infer least privilege from a friendly connection name, consent checkbox, or the maker's ownership of the agent. Verify sensitive reads as well as writes with separate authorized and unauthorized test resources.

Step 2: Select a deployable authentication mode

Use end-user credentials for interactive operations where caller-specific access is required. Copilot Studio environment settings can restrict maker-provided credentials. Do not apply that restriction blindly to autonomous workflows: event triggers can run with maker connections. Such a workflow needs a dedicated least-privilege connection account, fixed permitted resources, and the external-event admission control in AID-H-004.007. If the platform cannot preserve the required caller/trigger authority, do not publish that operation to that audience.

Step 3: Test the published surface

Use clean browser sessions and independent network vantage points to test anonymous access, an authenticated but unapproved user, an approved user, and a user from another tenant where relevant. Check every enabled channel, including direct links that bypass the usual website. Use synthetic private records and reversible test actions; verify downstream audit logs show the expected identity and denied resource access. A login page or HTTP 200 alone proves neither protection nor a leak. Retain version-bound results and exclude raw credentials or private records from evidence.

Apply AID-H-004.007 when a tenant-controlled receiver or a verifiable platform pre-run adapter can bind the event initiator and resource before creating a run. For provider-native triggers without that integration point, this publication gate owns native trigger configuration and execution-identity restrictions. Do not count a maker credential or publication approval as event-by-event authorization; restrict the workflow to approved event resources and effects, and deny release when the required authority cannot be constrained.

AID-H-004.006-G003

Reconcile publication state and handle drift with explicit coverage and containment handoff.
Step 1: Reconcile the complete published population

Consume AID-M-001.005 hosted-tenant inventory and compare exact agent, environment, channel, audience, version, and connection identities against the approved release records. Include unpublished-to-published transitions and platform-generated demo endpoints. Check each applicable setting individually: missing authentication metadata must not become false or a compliant default. Classic bots, inventory truncation, stale snapshots, and unsupported regions remain explicit coverage gaps until resolved through an administrative readback or another supported adapter.

Step 2: Block drift and verify containment

Block promotion on unexplained public access, excess sharing, new channels, expanded knowledge, or broader connector identities. For an already published violation, hand the exact tenant/environment/agent/version and observed channel list to AID-I-003 containment. Where supported, Copilot Studio quarantine blocks published end-user access, but does not disable maker testing and does not support every bot type. Its documented authorization uses a delegated administrator token; do not invent an app-only fleet-remediation capability. Read back the administrative state and repeat channel probes after containment. Permanent removal belongs to Evict; do not award a second isolation outcome for this handoff.

Open-source tools

Commercial / hosted tools

Threat mappings

MITRE ATLAS

MAESTRO

OWASP LLM Top 10 2026

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

NIST Adversarial Machine Learning 2025

Cisco Integrated AI Security and Safety Framework

Google Secure AI Framework 2.0 - Risks

Databricks AI Security Framework 3.0

AID-H-004.006: Hosted Agent Publication & Exposure Controls | AIDEFEND

Loading interactive view…

A Practical Knowledge Base for AI Security Defenses

Version