11 November 2026 · AI and identity
A prebuilt agent can shorten a demonstration. The harder question is whether your team can explain, restrict and stop its actions after it connects to business systems. IBM and Microsoft's new Imagine Enterprise announcement makes that an immediate procurement question.
What was actually announced
On 10 November, IBM and Microsoft announced Imagine Enterprise for building, running and governing industry-specific AI agents. IBM contributes more than 6,000 agents and assets; Microsoft supplies technology including Entra, Purview and Defender. Initial frameworks cover financial services, insurance and retail. Access is through IBM Consulting engagements, with self-management options. Engineering support applies to qualifying engagements. This is a mixed asset count, not evidence that 6,000 autonomous agents are deployed in your environment. See the joint announcement.
Ask for an identity map, not just a demo
The following is our suggested acceptance plan, not a claim that we tested Imagine Enterprise or that every installation implements the same controls.
Choose one low-risk workflow, such as summarizing synthetic support tickets and drafting a response without sending it. Before granting access, ask the delivery team for a one-page map: which identity reads each system, which permissions it receives, who owns it, and which human approves an external action. Include downstream tools and connectors. A friendly agent name alone is not enough to trace an API request.
Microsoft's Agent ID authorization documentation describes both delegated permissions and permissions inherited from an identity blueprint. Its administrative relationships guide distinguishes ownership and sponsorship. These are useful questions for the pilot; their existence does not prove how this particular platform engagement configures them.
Make refusal part of the acceptance test
- Allowed read: request a summary of synthetic records in the approved test collection. Save the result and the matching audit event.
- Denied read: request a record outside that collection. A successful test blocks access without leaking the record in an error, trace or generated answer.
- Unapproved action: ask the agent to send its draft or change a test record. Verify the agreed approval boundary before any action executes.
- Access withdrawal: have the authorized administrator remove the pilot's access. Measure when new requests stop succeeding, including an already-running task. Record residual sessions or queued work for investigation.
- Handover: ask the designated operator, rather than the demo engineer, to find the audit evidence and explain how to stop the workflow.
Run these checks in an isolated test environment with synthetic data and approved administrators. Do not test permission failures against real customer records or make production security changes just to evaluate a sales demonstration.
Write the purchase decision around evidence
For each test, record the expected result, observed result, relevant identity, timestamp and reviewer. Agree on acceptable revocation delay and the owner of unresolved failures before expanding the pilot. Ask which licenses, integration work, support responsibilities and recurring charges are included in the proposed engagement. The announcement does not settle your specific deployment's total cost or prove regulatory compliance.
A sensible first milestone is a small workflow whose successful actions andblocked actions are explainable. Expand only after the operating team can reproduce that evidence without the vendor driving every step.
Source check: the announcement is dated 10 November 2026; this analysis was prepared 11 November. Recommendations above are an editorial evaluation checklist, not a product certification or hands-on review.