Portability is not implementation evidence. An Agent Control Specification manifest can describe controls independently of an agent framework, but that does not prove that a particular Azure resource-provider profile accepts, interprets, or enforces every general ACS capability. Enterprise architects must qualify the exact profile they intend to deploy rather than treating specification compatibility as an inherited security property.
Separate announcement intent from implementation evidence
Microsoft’s Build 2026 announcement presents ACS as an open standard for deterministic safety and security controls. It describes five broad lifecycle areas: input, model, state, tool execution, and output. It also describes YAML policies and cross-framework portability. These statements establish the announced design intent, not a compatibility matrix or enforcement result for every Azure implementation. See the ACS announcement.
A separate Foundry Agent Service announcement places ACS within a proposed evaluation-and-enforcement workflow. That post assigns different lifecycle states to several adjacent Foundry capabilities. Those dated statements should not be converted into claims that ACS is generally available, uniformly deployed, or enforced for a particular resource.
The documented Azure profile is narrower
The supplied Microsoft.CognitiveServices/raiPolicy 2026-09-15-preview schema documents a subscription-targeted resource contract. Its ACS intervention-point object exposes input, output, pre_tool_call, and post_tool_call. Separate model, state, startup, or shutdown bindings are not visible in this profile and should not be inferred.
For ACS creation or replacement, format must be ACS, and acs is then required by service validation. Omitting format during creation selects ContentFilters, so merely recording the intended format is insufficient. The template must select it explicitly. Within the ACS manifest, agent_control_specification_version and named policies are required, as is at least one intervention point.
This profile supports only rego as its listed policy language. Standard annotator dispatch and intervention-point annotation bindings are disabled; if present, those objects must be empty. A tool selector requires a non-empty static tool catalog, and an unknown selected catalog key is documented to fail closed. Optional moderation bindings can request listed harm signals before Rego evaluation. When a detector configuration identifier is supplied, it must be supported for the selected category.
These restrictions describe this versioned Azure profile only. They do not establish equivalent behavior in another ACS host. Likewise, the general ACS announcement does not add fields or semantics absent from this ARM contract.
Validate before relying on a control
- Pin both versions. Record the resource type,
2026-09-15-previewAPI version, explicitACSformat, subscription deployment target, and declared ACS manifest version. Do not present this preview contract as generally available. - Validate documented fields. Check required properties, allowed intervention-point names, listed policy-target values, Rego definitions, empty annotation objects, and tool-catalog requirements. Do not claim undocumented cross-field combinations are prohibited without additional contract evidence.
- Verify environmental availability. Ask the target Azure control plane whether this API version and resource shape are accepted for the intended tenant and subscription. If regional dependencies matter to the associated workload, verify them separately; the supplied schema contains no universal availability matrix.
- Read back resource-level state. Compare the returned resource with the submission. Scope this check carefully: the schema identifies an egress header
valueas write-only and says effective egressdefaultActionandmodevalues are returned on GET. That does not guarantee read-back behavior for every ACS field. - Test documented enforcement paths. Exercise conditional allow and deny cases supported by the selected configuration. Collect whatever response, diagnostic, or telemetry evidence the deployed environment actually exposes. Do not presume ACS annotations, traces, or audit records: annotations are disabled in this profile, and separate content-filter actions or hosted-agent observability announcements are not an ACS audit contract.
Proposed assessment questions
These are proposed tests, not reported outcomes:
- Does each configured intervention point execute on its expected runtime path?
- Does an unknown selected tool key fail closed in the deployed environment?
- Can operators distinguish Rego evaluation failures from moderation-provider failures?
- For the exact blocking field under test, is the operation stopped or only signalled?
- Are the documented effective egress defaults returned after deployment?
- If comparable deployments are available, do they produce equivalent configuration and enforcement evidence?
- How does the service handle an unsupported declared ACS manifest version?
Architecture decision
Treat ACS as a portable contract and each provider/API version as a separately qualified implementation profile. Require schema validation, deployment acceptance, scoped read-back, and negative-path tests before approving a control. Successful execution can establish only that the tested configuration behaved as observed under documented conditions. It does not establish cross-provider equivalence, measured effectiveness, complete protection, general availability, universal deployment coverage, or SDK behavior.