Skip to main content

Enterprise Assessment Engagements

Use when operating M365/Azure assessment engagements. Use this class-level workflow for applications that assess Microsoft 365 and/or Azure tenants. Treat the engagement scope, service-principal credential, collection boundary, assessment denominator, and customer-facing report as one contract.

1. Establish workload scope before credentials​

For a new engagement, require an explicit selection of one or more workload families. For the M365/Azure pair:

  • Microsoft 365 only
  • Azure only
  • Both

Do not silently broaden scope. Validate the selection in both the renderer and the privileged process/API boundary. Persist it with the engagement and preserve it when reopening. Existing records without a scope may migrate to the historical behavior, but new records should require an explicit choice.

A workload being unselected means all of the following:

  • do not request its permissions or RBAC;
  • do not authenticate to or call its APIs;
  • do not emit progress, counts, errors, findings, or retained data for it;
  • do not include its controls in compliance denominators, dashboards, or exports;
  • state the selected scope in every customer-facing deliverable.

Test valid combinations, the empty invalid combination, hostile/unknown boundary values, backward migration, no-call behavior, denominator behavior, and export labels.

2. Separate public and private certificate artifacts​

Microsoft Entra receives only the public certificate. The assessment client needs the private key to sign authentication assertions. Never upload or transmit the private key to Entra, an issue, a log, or chat.

For apps whose credential contract accepts an unencrypted combined PEM, produce three distinct files:

  1. Public certificate — upload to Entra.
  2. Private key — protect locally; never upload.
  3. Combined certificate + private key — provide only to the trusted local application or OS credential vault.

Confirm the application’s actual credential parser before prescribing order, encryption, extension, or path behavior. A certificate thumbprint alone is not a usable signing credential.

See references/entra-certificate-credentials.md for the validated macOS/OpenSSL procedure and artifact-handling rules.

3. Validate PRs against current main without mutating them​

When a human must test an open PR after a prerequisite merged:

  1. Re-read the PR’s live state and head SHA.
  2. Verify the repository owner/name and clone URL through the live API before presenting commands. Preserve the identifier exactly; visually similar repeated underscores and misspellings are common failure points.
  3. Use a fresh disposable clone or worktree.
  4. Fetch origin/main and the PR head separately.
  5. Create a local no-commit integration merge on detached current main.
  6. Run install, tests, build, post-build native-module repair, and tests again when packaging changes native ABIs.
  7. Never push the disposable integration state.

See references/pr-integration-and-live-validation.md for the command pattern and evidence format.

4. Handle live-tenant evidence safely​

Use a tenant the operator is authorized to assess. Record counts and outcomes only—never tenant IDs, subscription IDs, user names, user principal names, secrets, certificate material, or customer configuration in public issues or chat.

Compare like-for-like semantics. For example, an active directory-role membership result should be compared with active assignments, not PIM-eligible assignments. If counts differ, stop merge readiness and open a focused defect; do not rationalize the mismatch.

An explicit human waiver may replace a human-only validation gate only when governance allows it. State the residual risk precisely; a waiver does not clear unrelated build, platform, review, or CI gates.

5. Owner-action and evidence triage​

When the user asks what they must do to unblock delivery, provide an owner checklist, not another fleet-status replay. Separate actionable now, prepare now but execute after a testable artifact exists, and engineering/manager-owned work. Re-read live issue acceptance, recent comments, exact PR heads, and recorded owner decisions: an old issue body or blocked card may be superseded by later execution evidence. Do not ask for an approval already given, or repeat a known-failing platform procedure without a changed prerequisite.

For each human action specify the decision/test, prerequisite, exact evidence, and safe recording destination. Native test requests require an identified candidate/artifact and a runnable checklist; a general request to “prove Windows works” is not actionable. Missing source-binding regeneration, reviewer dispatch, ordinary integration, and candidate assembly belong to the agents, not the owner. Trace apparent dependency cycles before escalating: requiring package evidence before the prerequisite that enables packaging is a sequencing problem to resolve, not an implicit request to waive acceptance.

Source-integrity verification is not human approval. Before requesting benchmark ratification, provide a fresh independently verified binding, readable old/new mapping comparison, exact fingerprints and their meaning, and a narrowly scoped approval statement. A changed extractor invalidates its prior binding. Do not solicit blanket approval of generated controls or stale hashes. Unknown severity representation, rated-risk policy, mapping approval, and automated-coverage claims are distinct decisions.

See references/owner-evidence-checklist.md for the evidence packet and platform/source/tenant acceptance distinctions.

6. Completion standard​

An engagement or PR is ready only when:

  • selected workload scope is explicit and enforced end to end;
  • permission guidance matches that scope;
  • credential public/private handling matches the application contract;
  • current-main integration and platform tests pass;
  • required live-tenant comparisons or explicit waivers are recorded without sensitive data;
  • exact-head review/CI requirements remain valid after any mutation.

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/engineering/enterprise-assessment-engagements/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/engineering/enterprise-assessment-engagements/ · view source · Imported 2026-10-04. Supporting files (references, scripts) remain in the source repository.

version 1.0.0 · author Hermes Agent · license MIT.

Published by Muse · 2026-10-04.