ENTRA AGENT BLUEPRINTS — ADMINISTRATOR TEST WORKSHEET
Version: 2026-11-11
Purpose: record a controlled test of the DEFAULT USER blueprint-creation setting.
This is a worksheet, not a tenant configuration script.

1. BEFORE THE CHANGE
Tenant / change reference:
Reviewer / change owner:
Current setting label and value:
Application-registration setting (a separate control):
Evidence time (UTC):
Test user's member/guest status:
Active and eligible directory roles / role-assignable group memberships:
Existing blueprints and principals / known owners and dependencies:
Test blueprint sponsor (required) and owner (recommended):
Cleanup operator and verified role/ownership for each target:
Approved maintenance window and final setting:

2. TEST RECORD — keep expected and observed results separate
For every test record: UTC time, account alias, setting, active role, unique
blueprint name, operation attempted, observed result, object IDs (privately),
error/correlation ID if present, audit event, screenshot reference.

A. Initial condition: user without an agent-creation role, setting as found.
B. Restricted condition: same user and client after No is saved and a fresh
   session is obtained. Attempt a NEW blueprint with a different name.
C. Authorized control: approved creator, setting remains No. Distinguish
   an existing administrator control from an Agent ID Developer exception.

Do not mark B as an API-denial test if only a disabled portal button was observed.
If a request fails, first distinguish authentication, wrong tenant, role,
propagation, client consent and service errors from the intended policy denial.
Record a failed/unfinished test as such; do not overwrite it with an expectation.

3. CHANGE BOUNDARY
This setting is tenant-wide. It is not a report-only policy or pilot-group rule.
Users can register applications = No does not replace the separate blueprint
creation control. Review both settings; user consent is another control.
Do not enable broad creation just to produce a before screenshot.
Use synthetic names and no data sources, client secrets, certificates, federated
credentials or resource-access grants. Review permissions assigned automatically
to the blueprint principal separately from access to business data.

4. EXISTING OBJECTS AND CLEANUP
Record existing/test blueprint names, application object IDs, application/client
IDs, principal object IDs and child identities separately. They are not interchangeable.
Where to read them:
- Agent blueprints > Choose columns > Blueprint Application ID: client/appId.
- Object ID in that same list: blueprint PRINCIPAL object ID.
- Blueprint > Developer settings > Manifest: application id and appId;
  match its displayName and appId before recording the application object id.
- Linked agent identities > select a child: that child's Object ID.
If needed, an already authorised Graph client can resolve the application by
appId using Microsoft's Get application procedure (Application.Read.All).
Read the manifest only; do not edit it to collect identifiers.
Check linked identities before any deletion. Delete only approved disposable lab
objects. Deleting a blueprint application can cascade to its principal and children.
Use Microsoft's supported deletion procedure; verify the final inventory.
Changing the tenant setting and deleting objects have separate authorization checks.
The deletion guide identifies Agent ID Administrator for agent identity management,
Cloud Application Administrator for the blueprint application/principal, and an
ownership path for associated agent identities. Confirm the exact scope before use.
The documented Graph/Entra PowerShell blueprint deletion also requires the client's
Application.ReadWrite.All permission. The portal lab required no new Graph grant.
Remove any temporary role assignment and recheck the account's original roles.
Record the final tenant setting and the rationale for retaining/restoring it.

5. SIGN-OFF
What was proved:
What remains untested:
Cleanup confirmed by / time:
Final setting and any residual objects:

6. WORKED EXAMPLE — observed on 11 November 2026
Initial state: Yes; zero blueprints and zero agent identities.
First test account: internal member with Global Reader. Creation button disabled
with Yes. No role change. Cause not established; not a usable successful baseline.
Administrative control A: account with Global Administrator, setting Yes.
Result: blueprint, principal and one linked identity created.
Change: only blueprint registration set to No; saved and refreshed.
Administrative control B: same account, new object, setting No.
Result: second blueprint, principal and one linked identity created.
No credentials or data-access grants configured in either test.
Audit: first principal's Add service principal event matched the actor and target.
Cleanup: both blueprints soft-deleted. The two children remained listed; each
was explicitly soft-deleted after matching its ID to the lab record.
Final inventories: zero blueprints; zero agent identities. Final setting: No.
Not proved: ordinary-user before/after enforcement, isolated Agent ID Developer
role, application-only creation, automatic cascade completion, restoration.

Microsoft documentation:
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-app-roles
https://learn.microsoft.com/en-us/entra/agent-id/create-blueprint
https://learn.microsoft.com/en-us/entra/agent-id/howto-delete-agent-identity
https://learn.microsoft.com/en-us/entra/agent-id/manage-agent-blueprint
https://learn.microsoft.com/en-us/graph/api/application-get?view=graph-rest-1.0

Keep real account identifiers and raw logs in your own restricted records.
Never include passwords, tokens or client-secret values in this worksheet.