Final runtime verification
Read-only Graph inventory at 13:10 confirms that both Casimir lab apps request no Microsoft Graph permissions. Both app-registration owner lists are empty: assign permanent named owners before rollout. Personal Excel and OneDrive OAuth completed; OneDrive drive listing succeeded and Excel workbook listing succeeded with a null result. Excel worksheet creation, six-row write and read-back succeeded. Two-user isolation remains an acceptance test.
Evidence: evidence/entra-app-inventory.json and evidence/microsoft-runtime-read-check.json.
Recommended arrangement
Andreas implements; Mike approves
Use andreas.petersson@cpc.com in the CPC tenant. Mike creates the initial registrations, keeps a CPC owner on each, and adds Andreas as owner of the Casimir registrations. Add ownership of the corresponding enterprise apps only when Andreas needs to manage pilot assignments.
Mike or the appropriate CPC administrator approves consent requests and publishes the Teams app. Andreas handles code, deployment, redirects, bot configuration, testing and the proposed tool matrix.
Mike performs the Microsoft setup
Andreas supplies an exact setup sheet: app names, tenant, redirects, scopes, endpoints, manifest and pilot users. Mike enters these settings in the portals while Andreas assists on a call.
The CPC administrator places the bot credential in the deployment secret store. Andreas needs code/deployment access and a pilot account; ownership of the Microsoft apps can remain with CPC.
These are proposed CPC arrangements. They have not been granted in CPC. App ownership allows credential changes and therefore use of that app's granted privileges; delegate it only to a trusted implementer. Microsoft: delegate app management.
What the Capacity lab actually used
This rehearsal runs in capacity.at, with andreas@capacity.at. It does not establish permission to change CPC's tenant, apps or files.
| Layer | Observed setup | What this proves / leaves open |
|---|---|---|
| Web sign-in and lab API | Single-tenant registration; SPA sign-in; delegated access_as_user for our own API. The default Microsoft Graph User.Read entry was removed. The SPA has no client secret. | Microsoft sign-in and own-API authorization were verified. The account's actual Entra administrator role and the exact app-owner assignments were not independently verified. |
| Teams bot | Teams-managed bot created with @microsoft/teams.cli 3.0.3; single tenant, personal chat, no manifest resource-specific permissions and supportsFiles: false. A bot client secret exists; recorded expiry is 7 October 2028. | Personal installation and a German invitation containing KASTANIE were verified using the approved synthetic MCP guide and real local MLX generation. Teams SSO is absent. The bot app's Graph permission pane still needs a final inventory. |
| Local model inference | Earlier Teams generation used the MLX Serve process on Octopus, outside Compose, with Qwen3.8-Flash-Next-Abliterated-MLX-Serve-mixed-4-8bit through host.docker.internal:18080/v1. The latest local probe timed out; DeepSeek awaits a validated key. The template generator and its fallback were removed. | Inference receives the task brief and synthetic MCP guide; it does not receive identity JWTs or Microsoft OAuth credentials. Identity, permissions and approved actions remain outside the model. |
| Setup tool authority | The CLI requests Teams Developer Portal AppDefinitions.ReadWrite and delegated Graph Application.ReadWrite.All. Its source uses the Graph scope for secret generation; the doctor report confirms an available Graph token and successful app/secret metadata reads. | This belongs to the signed-in setup tool, not the Casimir runtime app. The scope is broad and requires admin consent. We have not established when or by whom that CLI grant was originally consented. Microsoft permission reference. |
| Obot administration | Obot v0.26.0 uses a local Owner account. Authentication is enabled. A local AES-GCM field-encryption configuration is mounted. Microsoft upstream OAuth is separate from Obot login. | No Obot Entra sign-in or directory-read grant has been configured. Encryption protects selected fields, rather than the entire database or backups. Obot encryption scope. |
| Local infrastructure | Docker Desktop access on Octopus deploys Obot, harness, broker, Teams adapter and the synthetic knowledge MCP in one Compose stack. The existing local MLX service is outside that stack. SSH root access on hamster writes SWAG forwarding and reloads nginx. | These are powerful host privileges, distinct from Microsoft roles. Obot's Docker socket can control the Octopus Docker daemon. The broker and harness use constrained containers; that does not reduce the socket's authority. |
| Business authorization | config/policy.json binds verified tenant/user IDs to pilot, marketing, reviewer and operator roles. Tool/resource allowlists and exact-payload confirmation govern writes; publication is a synthetic dry run. | Payroll changes, employee creation, arbitrary shell, credential reads and mail sending are denied. This prototype matrix is a proposal for CPC; it is not derived from CPC groups yet. |
Safe evidence: compose.yml, config/policy.json, config/teams-manifest.json, evidence/teams-doctor.json, and the installed CLI's dist/auth/config.js and app/secret command source. No tokens, passwords or secret values were inspected for this memo.
Implementation verification: fourteen current source checks pass, including four link-candidate checks. Earlier fourteen live smoke checks passed. A consistent SQLite snapshot opened read-only preserved thirteen jobs and four synthetic publications with integrity OK (evidence/broker-backup-restore.json). Full service startup and Obot credential-store/key recovery remain unverified.
Permissions Mike needs to consider
| Work | Smallest practical delegation to Andreas | CPC decision / Mike-led alternative |
|---|---|---|
| App registration, redirects, own API scope and credentials | Owner of the specific Casimir registration. If Andreas must create registrations and ordinary users cannot, a temporary Application Developer role enables creation as owner. That role also permits some self-consent, so it is still privileged. | Mike creates the registrations and grants only their ownership. Tenant-wide Cloud Application Administrator or Application Administrator is broader and normally unnecessary for this pilot. The latter additionally covers Application Proxy. Role definitions. |
| Enterprise-app pilot assignments | Owner of the corresponding service principal / enterprise app can manage assignments. App-registration ownership and enterprise-app ownership are separate records. | Mike can retain enterprise-app ownership and assign pilot users himself. Group assignment requires Entra P1/P2; check CPC licensing, or use individual assignments. Group ownership manages membership; it does not approve OAuth scopes. Assignment prerequisites. |
| Teams development and installation | Access to the Casimir definition/bot in Developer Portal, plus an app setup policy allowing Andreas to upload custom apps. This does not require making him Teams Administrator. | A Teams Administrator controls custom-app policy and organization rollout. Mike can upload the reviewed package and limit availability to the pilot, using app-centric management or the tenant's existing permission policies. Custom app controls; app availability. |
| Tenant-wide delegated consent | Andreas prepares the exact request. Registration ownership alone does not authorize tenant-wide consent. | Cloud Application Administrator or Application Administrator can approve delegated permissions, subject to CPC policy. Mike or another CPC administrator can do this one approval without delegating the role. Consent roles. |
| Microsoft Graph application permissions | Keep approval with CPC. These operate as a workload rather than the signed-in file owner. | Consent to Graph application permissions needs Privileged Role Administrator or a suitably authorized custom role; the application-administrator roles above do not cover it. This matters if native Obot Entra login is adopted. Microsoft consent requirements. |
| Microsoft files and worksheets | Each pilot user signs in for their own delegated connector. Give Andreas access only to the agreed test workbook/folder, through normal Microsoft file sharing. | Mike/data owners approve the connector, publisher and scopes. Tenant consent never creates file ownership. Conversely, a file share is not consent to a connector. Each layer needs its own approval. |
| Obot, broker policy and deployment | Obot Admin for configuration; deployment access to the dedicated runtime; proposed policy changes reviewed by CPC. Owner access is needed for owner-level changes, not for every user. | Mike keeps a CPC Owner and controls pilot membership, secrets and sensitive tool rules. Hosting administrators manage the runtime/proxy. Do not delegate unrestricted Docker/root access to normal pilot users. |
Application.ReadWrite.All is its least-privileged Graph scope for the secret-creation API, but its name accurately signals a large setup-tool permission. A normal app owner can perform the operation for an app they own. Mike can create the secret in the portal instead, avoiding a new broad CLI grant in CPC. Microsoft: addPassword permissions.Two Microsoft integrations — two different permission decisions
1. Per-user Excel / OneDrive tools
The demo uses the Obot catalog's vendor-hosted endpoints, m365-excel-mcp.obot.ai and m365-onedrive-mcp.obot.ai. Andreas approved Obot.ai for the demo, with a requirement to replace it later. The service sits in the file-access path and can process file contents and Microsoft credentials needed for those operations. Excel catalog definition; OneDrive catalog definition.
Both public OAuth metadata endpoints advertise openid, offline_access, User.Read, Files.ReadWrite and Files.ReadWrite.All. Excel metadata; OneDrive metadata.
offline_access, Files.ReadWrite, Files.ReadWrite.All and User.Read. Andreas explicitly approved this request for the Capacity demo. Admin/discovery OAuth for both Excel and OneDrive reached Authentication Complete for the signed-in user. Personal runtime OAuth now reports all services authenticated; Obot Inspector reports Available. OneDrive drive listing succeeded and Excel workbook listing succeeded with a null result. Excel worksheet creation, six-row write and read-back succeeded. Two-user isolation and the independent Entra grant record remain unverified.This is organization-wide delegated consent, not app-only access to every file in the tenant. File operations still act for an authenticated user and within that user's rights. It is a broader approval than consent for Andreas alone, and it is not CPC approval. Before CPC adoption, Mike must review the publisher, exact app ID, resulting grant and data-processing destination. The vendor endpoint must be replaced as agreed.
The CPC connector should use individual Microsoft authorization, reviewed read/write tools and an enforced workbook/folder allowlist. A delegated grant can reach files already shared with the user; it is not automatically limited to a single demo workbook. Disable sharing-permission changes and deletion until CPC approves those operations. A replacement must repeat OAuth, user-isolation and resource tests.
The managed virtual MCP vmcp1rmdls exposes six Excel tools (list_workbooks, list_worksheets, get_worksheet_data, add_worksheet_row, add_worksheet_column) and four OneDrive read tools (list_all_drives, get_drive, get_drive_item, list_drive_items). Delete and sharing tools are not enabled in this managed surface.
2. Microsoft login and group lookup for Obot itself
Pending, separate approval: Obot's current v0.26 instructions for its native Entra login list delegated User.Read and ProfilePhoto.Read.All, plus application GroupMember.Read.All and User.Read.All. These directory reads are additional to Excel OAuth and have not been granted in this lab. Mike should approve their purpose and scope, or request a verified alternative. Entra login also requires Community registration or an Enterprise license. Obot Entra setup.
Microsoft login establishes identity. Obot access policies decide which MCP servers a user can reach; the broker decides permitted actions and resources; Microsoft decides which files that user can access. Remove broad everyone access from sensitive MCP policies. Obot access policy behavior.
A concrete handoff Mike can approve
- Confirm the CPC identity and pilot. Verify
andreas.petersson@cpc.comexists in the intended tenant, has the needed Teams/file service access, and uses CPC's MFA rules. Record tenant ID and the pilot's user object IDs. Do not copy Capacity tenant IDs into CPC configuration. - Choose the delegation route. For the recommended route, record Mike and Andreas as owners of only the agreed registrations, with CPC retaining a permanent owner. Include enterprise-app and Developer Portal ownership separately where required. If creation needs Application Developer, set an end date and remove it after bootstrap.
- Review a written permission request. Separate own-API sign-in, bot authentication, setup-tool scopes, user file OAuth and optional Obot directory lookup. Identify publisher, data destination, redirect, permission type and who consents. Avoid blanket approval of all later scopes.
- Grant only the pilot's entry points. Mike applies custom-upload policy to the developer and limits Teams availability/enterprise assignments to named pilot users. Data owners share a dedicated test folder/workbook. Define who may read, draft, edit, approve and publish.
- Deploy with CPC-owned secrets. Place bot credentials and encryption/workload keys in the approved secret store, document rotation and backup owners, and keep them out of source control and the slides. Restrict runtime management to trusted operators.
- Accept the evidence, then reduce access. After the checks below, remove temporary roles and setup grants that CPC no longer needs. Keep only agreed app ownership and deployment rights for maintenance, with a review date.
If CPC has licensed Privileged Identity Management, use eligible, time-limited activation for any necessary broad role. Otherwise Mike should record the access window and remove the assignment manually. CPC licensing and existing administrator roles remain unverified.
Acceptance and revocation checklist
- A pilot user can sign in; an unassigned user and a different tenant are rejected. Removing a pilot assignment/member must actually remove access.
- The bot is installed in personal chat only and a real message receives a broker-controlled response. No group/channel message reading or Teams SSO should be claimed without its own test.
- Two users authenticate Microsoft separately. One cannot reuse the other's connector token, job, approval or private context. Test both an allowed workbook and a forbidden resource.
- Show the final grant inventory for each application and setup tool, distinguishing delegated permissions from application permissions. Record consent actor, scope, owner, expiry and data processor.
- An unchecked confirmation cannot execute a write. Changed arguments, expired approval, cross-user approval and repeated delivery are refused or handled once.
- Test revocation through Entra consent/assignment removal and Obot account/connector access removal. Rotate compromised or transferred credentials; signing out alone is not a complete revocation plan.
- Back up state together with the keys needed to restore encrypted fields. Perform a restore check. Remove unnecessary CLI consent, temporary roles and deployer access after handover.
Lab identifiers for the handover record
Capacity tenant: cf5caa56-7cd8-496a-8ded-e0d57ba3c4cf
Web/API client: b1785104-df20-4bec-81ba-52e97d886be1
Teams bot/client: 71a69aff-c8fe-4ba5-a0a0-29270f9c9b0e
Harness: casimir-lab.home.petersson.at
Obot: casimir-obot.home.petersson.at
Compute: Octopus · public HTTPS forwarding: hamster SWAG.
These identifiers are public configuration references, not credentials. CPC will have its own tenant, app IDs, endpoints, identities and policy owners.