Security & deployment

Designed so the strictest review starts bored.

The security posture of AI Pulse is the product: read-only where observation is the job, explicit authorisation where enforcement is, and your data inside your boundary in both.

01Architecture

Your tenant is the perimeter

In its read-only posture AI Pulse deploys as a managed application inside your own Azure tenant. It authenticates with a read-only managed identity; there are no write permissions to grant, scope down, or accidentally leave broad. Asset data, telemetry and generated evidence stay in your tenant — nothing is shipped to us to “improve the product”.

With enforcement deployed it runs where your agents run — any cloud, self-hosted, sovereign, or fully air-gapped. Its decision ledger is tamper-evident and stays in-environment. Enforcement power is granted per agent, by you, and can be read back as policy at any time.

YOUR AZURE TENANT Azure AI servicesMicrosoft 365Power PlatformCost Management READ-ONLY · NO WRITE PERMISSIONS AI Pulse MANAGED APPLICATION READ-ONLY MANAGED IDENTITY You, signing in ENTRA ID · MFA No asset data, telemetry or evidence ever leaves the tenant
Deployment boundary (schematic) AI Pulse runs inside your Azure tenant and reads from Microsoft surfaces. Nothing crosses the boundary out.

02Deployment

Four steps, no agents, no writes

  1. 1

    Request your deployment package

    AI Pulse is packaged as an Azure managed application, provisioned directly into your subscription. An Azure Marketplace listing is planned.

  2. 2

    Deploy into your tenant

    The managed application lands in your own Azure tenant. A read-only managed identity is created — zero write permissions in the set.

  3. 3

    Connect your people

    Your team signs in with Microsoft Entra ID and MFA, under your existing conditional access policies.

  4. 4

    Watch the estate appear

    Discovery sweeps begin across your Microsoft AI surfaces. Systems are registered, tiered and mapped; evidence packs become available.

Nothing is installed on a host and no agent runs anywhere in your estate. Deployment creates a managed application and a read-only identity, and that is the whole footprint.

03Access & operations

Boring, on purpose

Identity

Your people sign in with Microsoft Entra ID and MFA — your conditional access policies apply. No separate credential store to defend.

Permissions

Read-only: a managed identity with zero write permissions, verifiable in your own tenant. With enforcement: scopes granted per agent, revocable, logged.

Residency

Data and evidence remain inside your tenant or environment. Sovereign and air-gapped deployments carry no external dependency.

Ledger integrity

Enforcement decisions are written to an append-only, tamper-evident ledger — the record is the evidence.

AI Pulse security view: attack surface, shadow agents, content-safety coverage and provider canary tiles, a risk-tier inventory, prompt-shield detections and red-team probe results.
Security posture Attack surface, unregistered agents and content-safety coverage, each tile naming the source it was read from. Categories with no live source read “Not measured” rather than showing a zero.

Detailed security documentation, architecture diagrams and penetration-test summaries are shared under NDA during evaluation. Request access →

04Identity & secrets

Who an agent proves it is, and how that proof gets rotated

An agent is only as governable as its identity. Agents authenticate either with a per-agent secret or with a workload identity token — verified signature, exact issuer and audience, expiry, and a binding claim that must resolve to that exact agent in the registry. A token that fails never falls back to a secret.

Moving from shared secrets to per-workload identity is a migration, so it runs in dual mode and stays off until you deliberately enable it. Two rules hold throughout: the shared platform identity is forbidden as an authentication subject, and a decision record stores only which mechanism was used — never a token, a claim or a secret.

Rotation stages new values under separate names on the services already entitled to hold them, changing nothing live until every holder has accepted its staged value. An interrupted run resumes from its checkpoint and replays the same values rather than generating new ones. Values are never printed; progress is reported as counts, and a failure names the holder and the secret it was missing.

Design decisions

  • Credential escrowNone, deliberately
  • Shared identity as subjectForbidden
  • Failed tokenNever falls back
  • Secrets in evidenceNever recorded
  • RotationStaged, then promoted

There is no central credential store, because one would become a single all-credentials target. Build logs, artefacts and repository files are not treated as acceptable secret stores either.

05Why this shape

Procurement-friendly by design

Direct deployment

Provisioned straight into your Azure subscription — no source access, no custom build. A Marketplace listing is planned, so it can count against existing Azure commitments once live.

Managed application

The application lives in your tenant under a managed resource group. You can see every resource and every permission — including the absence of write access.

Verified before purchase

We check discovery coverage against your licence tiers during evaluation, so what you buy is what you saw working.

Every component, licence and blast radius →

Review coverage & prerequisites →