Skip to main content

🛡️ Beak AI Security – Release Notes

Changelog for policy enforcement, scanning, and guardrails.

Version 6.0.0​

SOC 2 scoring, and a period report an auditor can sample​

The Compliance Dashboard engine now scores SOC 2 — the Security Trust Services Criteria (Common Criteria) — and the daily posture history it started recording last release can be read back for any date range.

  • GET /compliance/soc2. Same response shape as the EU AI Act, NIST AI RMF and ISO/IEC 42001 routes, each criterion under a criterion key: CC3.2, CC4.1, CC6.1, CC7.1, CC7.2, CC7.3 and CC7.4. CC8.1 (change management) is deliberately not scored — its evidence lives in Azure DevOps, not here. soc2 also appears in GET /compliance/summary and in the daily snapshots.
  • CC4.1 is proved by the recording itself. A new continuous_monitoring control is active once at least one daily snapshot exists for the tenant. The first day records it inactive, every later day active.
  • GET /compliance/report?framework=&from=&to=. For any registered framework and any inclusive date range, the daily score series, first/last/min/max/mean, days requested against days evidenced, and per-control counts of days active, inactive and check_failed — built from stored snapshots only, never recomputed. A window with no snapshot answers "no evidence in range" with a null score, not a zero.
  • New permission compliance:export gates the report. The analyst and admin system roles receive it on startup; viewer keeps read-only access to today's scores. Custom roles need an explicit grant.
  • GET /compliance/frameworks lists every framework the service scores, so clients can stop hardcoding the list.

On by default; nothing to enable. The SOC 2 criteria and weights are engineering's proposal pending product-owner sign-off and are data in the service. Dashboard cards for SOC 2 and the period report follow in a later release.

Every MCP tool call is now authorized​

Beak authorized MCP tool calls only on connections owned by an agent. Every other connection — a person's own credential, or one shared across a tenant — reached its MCP server with nothing consulted. All three scopes are now authorized, and a connection that is not owned by an agent is authorized as its owner.

  • What you can now do. Grant a principal access to a specific credential or server, narrowed to named tools, with an authentication mode and an expiry. Write rules about the tools themselves — "require approval for close_ticket on ITSM", "never allow delete_* on Jira" — that apply whoever is calling. See MCP Authorization.
  • Is anything refused on upgrade? No. Credential grants were inferred from the credentials your agents and people already use, and enforcement ships off, per tenant. Beak records what it would have refused so you can read the numbers before switching a tenant on. Resource policies do take effect immediately — and none exist until you write one.
  • Agent runs get their own token. An agent run now carries a token specific to that run, which expires and identifies the agent and the delegating person. Long-lived connection tokens keep working, so nothing needs changing. Revoking a connection now also revokes the run tokens issued against it, which previously stayed usable until their own expiry.
  • What it costs. Nothing new to provision. One new permission, mcp_servers:decide, which administrators already hold — it is needed only to mark an external server converged or exempt, and is deliberately withheld from the analyst and viewer roles so that reading the estate does not let somebody clear its outstanding work. External MCP servers are being routed through the Hub so they inherit the same protections as first-party ones; a server that genuinely cannot be proxied is marked exempt with a recorded reason.

Compliance posture is now recorded every day​

The Compliance Dashboard scores your controls live, at the moment the page loads, and kept nothing. That answers "what is our posture now" and not the question an ISO/IEC 42001 or SOC 2 auditor asks: "what was your posture on 1 August, and what proved it?" AI Security now records the answer automatically.

  • What is stored. Once a day, for every framework the service scores — EU AI Act, NIST AI RMF and ISO/IEC 42001 — a snapshot of the overall score and the full per-clause breakdown, plus one evidence row per control saying whether its check found the control active, inactive, or could not run at all (check_failed). That last outcome is recorded on its own rather than counted as inactive: "we could not verify" and "it was off" are different findings.
  • Same engine as the dashboard. A snapshot and a live read taken at the same moment agree. Nothing about the live scores changes.
  • Immutable, kept 13 months. Snapshots and evidence are never edited once written, and are removed only by the retention purge after 13 months — one SOC 2 audit window plus a month.
  • One per day, restart-safe. At most one snapshot per tenant, per framework, per UTC day. A restart mid-day does not record twice. Operators can change the interval with COMPLIANCE_CAPTURE_INTERVAL_SECS; a shorter interval cannot produce duplicate history.
  • On by default, nothing to enable. Recording starts with this release. Reading the history back — a past date's score and the evidence behind it — is covered by the period report in the entry above.

Every MCP server your agents can reach, in one list​

An agent reaches the outside world through MCP servers, and each one holds a credential the agent acts with. That estate lived in two places that never reported to a third — the shared catalogue and per-tenant connections in Beak AI Hub, and whatever someone registered directly in Beak AI Studio, which is usually the larger half. Nothing in Beak AI Security could list it.

MCP Inventory now reads both and reports what the combination is doing wrong: connections an agent can use that are authorized as a person rather than as that agent, servers registered on temporary developer tunnels, credentials pasted into a configuration, credentials no agent uses, and servers that quietly changed what their tools claim to do.

  • On by default, and empty until you sync it. The inventory is refreshed by an operator action, not a background job. Nothing appears until someone holding mcp_servers:sync runs one.
  • No credential leaves Hub or Studio. Beak AI Security stores metadata and a one-way fingerprint of each encrypted credential — enough to see that a secret was rotated or a connection re-pointed at another account, and not enough to read it.
  • Coverage is shown, not assumed. If one source cannot be reached, the other half is still inventoried, nothing is deleted, and the unread source is reported as a finding rather than counted as zero. Existing installations should confirm with their administrator that both Hub and Studio are reachable from Beak AI Security in each environment — where they are not, that half of the estate reports as Never read until the connection is configured.
  • Permissions. mcp_servers:read is included in the analyst and viewer roles; mcp_servers:sync is included in analyst. Both are granted to existing system roles on upgrade. A custom role needs them added. The sync reads as you, so the Beak AI Hub half additionally requires tenant-administrator rights — its inventory spans every user's connections.
  • AI Bill of Materials can now record an MCP server as a component — see AI Bill of Materials.

Read more: MCP Inventory.

Every MCP tool call is now evidence, not a log line​

MCP Inventory listed what exists. It could not say what happened. An agent's MCP tool call left a line in a service log and nothing else — no record you could show anyone of which agent used which credential against which server, whether the call was allowed or refused, and what the far end answered.

MCP Call Evidence writes one row per tool call, and one per OAuth grant action, into the same tamper-evident audit chain as your moderation history.

  • On by default, and retrospective from this release forward. Recording begins when Beak AI Hub is upgraded; calls made before it are not backfilled, because there is nothing to backfill from.
  • Every connection, not only agent-bound ones. A connection scoped to a tenant or to a person is precisely where an agent acts with a human's credential, so those are recorded too.
  • Refusals are recorded as fully as successes, each with a stable decision code.
  • No credential, no tool argument, no caller token reaches Beak AI Security — the credential is reduced to the same one-way fingerprint MCP Inventory already shows.
  • Two new findings. A credential the server keeps refusing (High) fires on five or more 401 or 403 refusals on one connection in 24 hours where at least half of its calls failed. A server with no call evidence (Low) reports access granted and a secret stored for something nothing uses; it is suppressed while the first is open for the same server.
  • One call, three places. Beak AI Agent Runtime's trace id is now carried through Beak AI Hub onto the audit row and onto the MCP server's own per-call line, so a single identifier ties the agent run in Beak AI Observability to the credential decision and to what the server saw — including whether the call arrived carrying a person's identity.
  • No new permission. The evidence is read with mcp_servers:read, the same permission the inventory uses.

Read more: MCP Call Evidence.

Governed Beak agents now show who is accountable for them​

The Operational owner on the Agent Passport was blank for almost every governed agent — 159 of 164 on a representative estate. The address was never missing, only unrecorded in Security: an agent built in Beak AI Studio already knows which user created it, and that user's address was never copied across when the agent was brought under governance.

Upgrading fills it in for agents built in Beak, from the creator Studio already recorded.

  • What this changes for you. The owner appears on the passport and in the registry where it used to be empty, so "who do I call about this agent" has an answer without asking around. It also means Beak can re-issue an agent's identity on its own if that identity is ever lost — re-issuing requires naming an accountable person, so an agent with no owner recorded had to be repaired by hand.
  • An owner you typed is never replaced. Only an empty field is filled. If someone recorded a team name rather than an address, that entry is left exactly as it is — it stays visible as the accountability record a person chose, even though Beak cannot use a team name to re-issue an identity.
  • Agents from other estates are not affected. Agents discovered in Microsoft Agent 365, iGentic or LangGraph have no Beak record to read a creator from, so their owner stays empty until someone sets it. On the estate above that is 11 agents of the 159.
  • On by default, nothing to enable, and no change to what any agent may do. It writes one field. No permission, scope, credential or policy is altered, and no agent's behaviour changes.
  • New agents arrive with an owner already recorded. An agent built in Beak is brought under governance by a discovery sync, and that sync now carries the creator across with it. So the owner is filled in when the agent first appears rather than repaired afterwards, and the one-time fill below is not something that needs repeating.
  • Applies as each environment updates. The fill happens once, when that environment's Beak AI Security starts on this version.

Where to read more: Agent Passport.

The two authorization layers now say which is which​

Agent authorization shows tool access and the credential ceiling together. Both are lists of named grants, which made them easy to read as one setting shown twice. They are now numbered stages, each labelled with the moment it is consulted — checked on every tool call against applied when a credential is issued — and each says the shape of its grant set, because one is graded and the other is not.

  • What this changes for you. Nothing about what your agents may do. It is presentation only, so that the answer to "which of these is refusing my agent" is on the screen. A scope_insufficient refusal is always tool access.
  • Enrolment tokens use the same editor. Minting a token used to offer a bare text box for the scope ceiling, so scopes chosen when an agent was first enrolled were chosen with no guidance, while the same field edited later listed every scope with an explanation. Both now show the same list and the same warnings. The token form still starts with agents:invoke selected.
  • On by default, nothing to enable, no existing grant changed.

A new tenant arrives with the guardrail baseline installed​

Creating a tenant now installs AI Security for it: its schema, the full built-in validator catalogue, the baseline guardrails and the default policies. These used to be copied from an existing tenant, so a tenant provisioned any other way started with an empty validator catalogue.

  • The optional redaction policy is not installed by default. It disables the competing block and warn rules so redaction can win, which weakens a tenant's posture — that is an administrator's decision, not a provisioning default.
  • The setup checklist distinguishes installed from in force. Provisioning installs policies; putting one in force and scoping it stays with the tenant, so that step waits for a person rather than completing itself.

On by default for newly created tenants; existing tenants are untouched. See What Each Product Sets Up.

The credential scopes an agent can hold are now named and explained​

The credential ceiling in the Agent authorization dialog used to be an empty text box. It now lists every scope a credential can carry — with a plain-language line for each — so choosing one no longer depends on knowing the vocabulary already.

  • What you can now do. Tick agents:invoke, agents:read, agents:write, agents:authorize, mcp:invoke or mcp:exchange and read what each allows, instead of typing a string and hoping. Typing still works, and the two stay in step.
  • Why it mattered. An agent's authority is the intersection of its scopes with the caller's, and an empty intersection means no authority rather than unrestricted. So a misspelled scope saved successfully and then authorized nothing, with no error anywhere. A scope that is not one the platform checks is now flagged before you save.
  • Integration modes are called out as a category error. gateway.llm, hub.tools, inference.hook, tool.hook and registry.only describe how an agent is integrated with Beak, not what it may do. Entering one as a scope grants nothing, and the dialog now says so instead of accepting it silently.
  • Still not an allow-list. The field accepts a scope that is not listed, because the platform keeps no allow-list and a new scope has to be introducible — the list is guidance, not a gate.
  • On by default, nothing to enable, and no existing grant is changed. Agents keep exactly the scopes they hold today. Saving continues to revoke outstanding credentials, as before.

Fixed — tool access was unreachable from the identity side of the authorization dialog​

Opening Agent authorization from an agent's identity (Agent governance) always reported "No registry profile for this identity", even when the agent had one — so the tool access half of the dialog, the layer that actually refuses a tool call, could not be reached from that entry point. Opening the same dialog from the Agent Registry was unaffected. Both entry points now show both layers.

Agent Passport — one screen for everything known about an agent​

Clicking an agent in the Agent Registry now opens its Agent Passport: identity, the accountable humans, capabilities, authority, risk, validity and history, on a single page. Previously that detail was split across four separate panels on four screens, so no one view answered "what is this agent, who answers for it, what may it do, and what has it done".

  • What replaces what. The registry's small detail modal is gone; the passport is the whole record. Key management — Generate, Rotate, Revoke — moved with it. Clicking a row, or the eye icon, opens the passport, and it has its own URL you can share or open in a new tab.
  • On by default, nothing to enable. Every existing agent has a passport immediately. No migration step, and no change to how agents are registered, governed or enforced.
  • Five new fields are yours to fill in. Business owner, sponsor, developer, environment and geography are recorded by an operator and are empty on every existing agent — nothing in the platform can discover them. They read as Not recorded until set, which is the point: an empty accountable owner is a governance gap, not a blank field. Newly registered agents can carry them from the start. Approved at, Expires at and Review by join them.
  • Expiry and review are recorded, not enforced. Beak does not yet refuse an agent whose registration has lapsed; the passport surfaces the date so a review can act on it. Turning on enforcement would refuse every existing agent, since none has an expiry recorded, so it is a separate change.
  • Capabilities are shown as declared and observed. What the registering system claimed sits beside what the agent's own recorded traffic proves, per dimension — models, tools, MCP servers, data, external APIs and other agents. They are never merged, because the gap is the finding: used but never declared, or declared and never used.
  • Sections you cannot read are named, not hidden. The passport spans several separately-granted permissions. An account with agents:read but not audits:read sees the identity and authority record with the evidence sections marked unavailable — never an empty panel implying the agent has been inactive.
  • The risk section states what it does not measure. It shows the existing six evidence factors under their own names. Data risk has no dedicated factor, financial risk is not an input, and the reliability factor has no source writing to it — so it measures zero for every agent, which is reported as unmeasured rather than left to read as clean. The risk score itself is unchanged, including the value pushed to Entra for Conditional Access.
  • Exportable. CSV and PDF of the entire record for an audit pack, carrying the same Not recorded wording as the screen.

Also fixed: an agent's governance decisions were matched on one identifier only, so every Copilot Studio decision was omitted — the panel read "No decisions recorded" for agents Beak had been actively blocking. Copilot Studio records the agent id in a different place from the other writers, and both are now read.

ISO/IEC 42001 scoring, first through the API​

Beak now scores your organization against ISO/IEC 42001, the AI management system standard, alongside the EU AI Act and NIST AI RMF. Eight clauses are tracked — risk assessment, impact assessment, internal audit, corrective action, and the Annex A controls for resources, life cycle, data and third parties — each backed by controls you already have evidence for. See Compliance Dashboard.

  • Where to find it. GET /compliance/iso-42001 returns the score with a per-clause breakdown and the missing controls for each clause; GET /compliance/summary gains an iso_42001 entry. The dashboard card arrives in a later release; the existing EU AI Act and NIST gauges are unchanged.
  • One clause is a declared gap. Cl. 9.2 Internal audit has no Beak control behind it and always scores 0, so the highest score reachable today is 90%. It is reported rather than hidden so the gap is visible in the number you act on.
  • Nothing to enable. Every clause draws on evidence the platform already records.

One place to set what an agent may do​

An agent's authority is decided by two layers, and until now they were edited in two different screens with similar names: allowed scopes in the Agent Registry, which tool authorization checks on every call, and Edit scopes on the Agent governance page, which sets the ceiling a credential is minted with and is never consulted when a tool call is authorized. Nothing on either screen said which was which, so an agent refused for want of a scope was routinely "fixed" in the place that could not fix it.

Both now open one Agent authorization dialog showing both layers together, and it states the answer to the question an operator actually has: a refused tool call is always tool access.

  • Nothing to enable, and nothing changes about what either layer does. This is the same two fields with the same meanings, in one screen instead of two. Neither is renamed on the API.
  • Two saves, not one. Tool access and the credential ceiling are written to different places, and saving the ceiling revokes the agent's outstanding credentials while saving tool access does not. Each has its own button so it is always clear what a save did.
  • It tells you when a layer does not apply — an identity with no registry profile has nothing checking its tool calls; an agent with no identity has no credential ceiling to set. Both are real states and are named rather than shown as empty editors.

See Agent Registry — Editing an agent's scopes.

A saved scope change now takes effect on the next tool call​

Saving an agent's allowed scopes could leave the old scopes enforced for up to five minutes. The console showed a success message, the registry row showed the new scopes, and the agent kept being refused — citing the scope set you had just replaced. Every signal said the change had landed.

The cause was that an agent is cached under whichever of its ids the caller presented, and only one of those ids was being cleared on a save. Every id an agent can be known by is now cleared together.

  • Nothing to enable. It applies to every save, and to key generation, rotation and revocation.
  • Revocation is the one worth knowing about. The same gap could leave a revoked signing key honoured for up to a minute after you revoked it. It is cleared immediately now.

An agent that registers itself can call tools​

An agent that registers through the API without naming its scopes — which the SDK snippet tells integrators to do on every boot — became governed holding only read, so every tool call it made was refused. This was the last remaining path with that behaviour; the others were fixed earlier in this release.

Registering now confers the same grant every other route confers when an agent becomes governed. An agent registered as a candidate still receives nothing, and scopes you name explicitly are always honoured exactly as sent — including a deliberately narrow read, and including none at all.

  • No existing agent changes, and a re-registration on the next boot cannot widen scopes you narrowed by hand. Registration has never been able to change an existing agent's grant.

A newly governed agent can call tools, and you can change its scopes in the console​

An agent that had just become governed held only read, so every tool call it made was refused — including agents Beak runs itself, the moment they were created in Studio and picked up by the inventory sync. Any tool that does not declare a scope of its own requires execute, and most do not declare one, so the agent looked correctly configured in the registry and worked for nothing. Becoming governed now grants read, write and execute.

  • Nothing to enable, and no existing agent changes. The grant applies only to an agent that holds no scopes when it becomes governed. Any agent whose scopes you have already set — including one you deliberately narrowed — is left exactly as it is, through re-adoption and every later sync.
  • One flow for every source. Adopting a discovered candidate, promoting an agent after first contact, and the Runtime or Microsoft Agent 365 sync all grant the same thing. An agent Beak runs is not treated differently from one discovered in another estate. The adopt confirmation now says what it will grant.
  • A profile you add by hand is unaffected — it still uses the scopes you pick in the form.

You can also now change an agent's allowed scopes from the Agent Registry: the shield icon on a governed agent's row opens a picker over read, write, execute and admin, and tells you which lower scopes your selection already covers. Previously this field could only be set when the profile was first created, so an agent refused for want of a scope had no path to a fix in the console. The icon is highlighted for an agent holding no scopes at all — governed, apparently live, and refused on every tool call. Requires agents:update.

This is a different field from the credential ceiling, which sets an agent identity's granted scopes — the maximum its credentials are minted with, and what an autonomy grant is drawn from (see the entry below). The scopes described here are the ones tool authorization checks, and an agent refused on a tool call is fixed with these.

The two fields remain distinct, but they are no longer in separate screens: later in this release both were brought into one Agent authorization dialog, which names which layer governs a tool-call refusal. See One place to set what an agent may do above.

See Agent Registry — Allowed Scopes.

NIST AI RMF scores can now reach 100%​

The Measure function on the NIST AI RMF card was capped at 75% for every organization: one of its four controls pointed at a check that did not exist, so nothing you configured could satisfy it. That control now maps to fairness monitoring — the same check that missing: fairness_monitoring already told you how to clear — so Measure can reach 100% and the overall NIST AI RMF gauge rises accordingly. See Compliance Dashboard.

  • Nothing to enable. On the next deployment the Measure card and the NIST gauge rise automatically for any organization that has run the Fairness Audit tool. No configuration changes.
  • EU AI Act scores are unchanged. Only the NIST Measure function was affected.
  • A framework the scorer does not know is now an error. Each framework is resolved from a registry, so a request for one that is not registered fails instead of returning another framework's numbers under the wrong label. The two frameworks on the dashboard behave as before.

Assign an agent's scopes, then grant it autonomy​

You can now set what an agent is allowed to do from the governance console, using Edit scopes on an agent identity. This closes the gap that made a discovered agent ungovernable: an autonomy ceiling can only be drawn from the scopes an agent already holds, and most agents are registered with none, so Grant autonomy had nothing to work with and no way to fix it. Where the console blocks a grant for want of scopes it now links straight to the editor.

Saving new scopes revokes that agent's outstanding credentials, because each one carries the scopes it was minted with — the agent picks up a fresh credential on its next run. Setting scopes needs agents:update; granting autonomy still needs agents:authorize. Nothing to enable, and no change to any agent's existing scopes or grants. See Agent governance.

Grant autonomy tells you why it cannot be granted​

The Grant-autonomy form no longer offers a ceiling scope that the agent does not hold. An agent registered without any scopes now says so and the grant is blocked, instead of accepting the form and failing on submit. When a grant, review, suspension, revocation or enrolment token is refused, the console shows the reason Beak IAM gave — a ceiling wider than the agent's own scopes, a grant that is already active, an operator who is not a user of the tenant — in place of the HTTP status code it used to show. Nothing to enable, and no change to which grants are allowed. See Agent governance.

Grant agent autonomy without a Beak IAM administrator account​

Granting, extending, suspending and revoking autonomy, revoking an agent credential, and minting or revoking an enrolment token now work for any console user who holds agents:authorize. Until this release Beak IAM also required the operator to be a Beak IAM administrator (a platform admin, tenant admin or delegated admin), so a tenant's own security operators were refused with a 403 even though the console had let them in. Beak IAM still resolves the operator to a real, active user of the tenant and records that person on the grant; it no longer demands administrator standing, which is platform administration and not tied to any product. Nothing to enable, and no change for operators who already were Beak IAM administrators. See Agent governance.

Find the agents running on iGentic​

A new discovery integration lists every flow on iGentic 2.0 and brings each flow's orchestrator and member agents into the Agent Registry as candidates, before any of them has called Beak. An agent that belongs to several flows is one row that records all of them. The integration is off until you save a credential; existing installations see the new card under Agent Platforms on the next deployment and nothing else changes. See iGentic.

  • What it needs. An application id registered with iGentic and its API key (the X-App-Id and X-Api-Key headers), both issued by the iGentic platform team. The card's What this connection needs panel lists exactly those two.
  • What it records. Agent ids, names and types, and the flows they belong to. No run history, prompts or configuration.
  • Two ways to govern them, one key. Per agent, choose Gateway mode — iGentic's Azure OpenAI client points at the Gateway's new Azure-shaped route with a single integration key, and Beak resolves the per-agent key it holds from the agent's GUID on each request — or Hooks mode, where iGentic calls Beak before and after every model call and every tool call. The integration key is generated once on the card and is the same secret for both. See iGentic.
  • The card tells developers what to type. The iGentic card gains an Integrate iGentic panel that prints the Gateway endpoint, the hooks base URL, the headers and the request bodies for the Beak host you are signed in to, plus the deployment names the integration key's Gateway team may call, with a copy button per mode. Nothing to enable, and it never shows the integration key itself.

Hook verdicts on the way out, and a ledger row for every tool call​

Two changes to the receivers every hook platform uses, both off unless a caller asks for them:

  • Completions can be enforced. A caller that holds the completion until Beak answers sends caller_applies_verdict: true with direction: "output"; a block is then recorded as a block and the response says enforced: true. The Gateway never sets the flag, so its completion scans stay detection-only exactly as before.
  • Tool results are judged. The beak tool-hook frame takes direction: "output" with the tool's result; Beak answers allow, redact with the redacted text, or block — do not hand this result to the model. Authorization does not run on a result; the call already happened.
  • Every tool-hook call leaves a row. Allowed calls and results now land on the same ledger as refusals, and hook-sourced rows keep the whole scanned text rather than the Gateway's excerpt, so an incident can show what was actually blocked.

One integration key for a whole deployment​

A virtual key of kind integration acts on behalf of many agents: the deployment presents it with x-beak-agent-id set to the agent's own platform id, and the Gateway runs the request as the per-agent key Beak minted at adoption — spend, limits and identity are the agent's, inside the deployment team's ceiling. An agent nobody adopted is refused with agent_not_adopted and recorded as a governance event; the key can never spend anonymously. Beak AI Security can register a key it minted (POST /aigateway/keys/register), which is how one secret serves the hooks and the Gateway, and a rotation re-parents the per-agent keys without re-issuing any of them. The Gateway also serves Azure OpenAI's request shape at /openai/deployments/{deployment}/chat/completions with the key in the api-key header, so an Azure-shaped client changes configuration only.

Agents refused at the Gateway show up on the posture panel​

When an integration key names an agent nobody adopted, the Gateway refuses the call and now also reports it to Beak AI Security, which records it in its own ledger. The Onboarding posture panel gains a medium finding, refused at the Gateway, not adopted, counting the distinct agents refused in the last 24 hours and naming the ones a connector has already found. Nothing to enable: it is on for every tenant whose Gateway Manager is configured to report governance to Security (the same setting that reports key issuance). Read more in iGentic and Agent onboarding.

See what is not protected yet, and how long onboarding really takes​

Agent Governance gains an Onboarding posture panel: findings for the conditions that read as governed and are not — Copilot Studio in log mode or allowing on timeout, prompt decisions that proceeded uninspected, Foundry bring-your-own-model traffic with no inline policy, agents that declared a level and never crossed it, discovered agents nobody onboarded — each with its count and remediation. Beside them, two clocks: minutes from saving a connector to its first candidate, and minutes from registering an agent to its first governed decision, as medians over the tenant's own history. See Posture.

  • Computed, not stored. Every figure comes from the tenant's audit rows, profiles and integration settings on each load; nothing is estimated, and a clock with no samples says null with the sample count beside it.
  • Fail-open becomes a line item. The market default at the tool boundary and Beak's own scan behaviour are shown as counts, not footnotes.

Note: Read-only; requires agents:read. Existing installations see the panel on the next deployment with whatever their evidence already says.

Find the agents on Foundry, Vertex AI Agent Engine and AgentCore — or in your telemetry​

Three more discovery integrations enumerate agents Beak could not list before: Azure AI Foundry Agent Service (Entra app with the Azure AI User role), Google Vertex AI Agent Engine (OAuth2 token with aiplatform.reasoningEngines.list) and Amazon Bedrock AgentCore (bedrock-agentcore:ListAgentRuntimes; a different resource from classic Bedrock Agents). Alongside them, a passive OpenTelemetry receiver at POST /aisecurity/hooks/otlp/v1/traces turns any framework's gen_ai.* spans into inventory for the cost of one exporter setting. See Integrations and Finding the agents nobody onboarded.

  • Every connector now states what it needs. A "What this connection needs" panel on each discovery integration lists the exact permissions, read from the connector rather than typed into the console.
  • Foundry's bring-your-own-model path is documented as the way its agents reach the Full Gateway level; the onboarding catalog marks it available.
  • Discovered and observed agents are candidates. Coverage observed, tier registered, nothing enforced until you onboard them — the receiver grants no boundary by design.
  • Every enumerable platform is in the Discover menu. The Agent Registry's Discover agents menu and the wizard's Not listed yet? row now offer all seven platforms, including Azure AI Foundry Agent Service, Google Vertex AI Agent Engine and Amazon Bedrock AgentCore, and name the integration to add when one is not configured.
  • Copilot Studio agents pick up their names on their own. An agent that first reached Beak through the external security hook carried only its bot id. Once a Power Platform credential is saved, the background discovery tick enumerates Copilot Studio and fills in the display name without anyone clicking Discover.
  • Coverage follows the evidence for known agents too. An agent registered by hand and then seen crossing the inference or tool hook on its own credential now shows that coverage, instead of staying Observed only because it was registered first.
  • Every configured platform is enumerated in the background. Bedrock, AgentCore, Foundry, Vertex AI Agent Engine, Agentforce and A2A now join Copilot Studio on the background discovery tick, so names and inventory stay current without clicks.
  • OpenAI Assistants discovery is retired. OpenAI sunset the Assistants API on 26 August 2026 and its replacement lists nothing. The card is gone from the catalog; a credential saved before reports the retirement when tested. OpenAI Agents SDK agents are still found from traffic.
  • Google Agent Engine takes a service-account key. Save the key once and discovery keeps working; the previous one-hour access token still works for a one-off check.
  • AWS connectors require both key parts and record no runtime secrets. A Bedrock or AgentCore integration with a missing key is refused rather than falling back to Beak's own cloud identity, an expired or invalid key reads as a credential problem rather than an outage, and an AgentCore runtime's environment variables and execution role are never stored.
  • A2A agents are keyed by their URL. Two agents that share a display name are two records; internal and cloud-metadata hosts are refused; agents on A2A 0.2 (agent.json) are discovered.
  • Agentforce and Copilot Studio listings read every page, and a refused Salesforce or Entra credential is named as such instead of reading as an outage.

Note: The OTLP receiver reads OTLP/HTTP JSON behind a broker token and refuses protobuf with a 415 naming OTEL_EXPORTER_OTLP_PROTOCOL=http/json. Existing installations gain the three integration cards and the endpoint; nothing is enumerated until a credential is saved or an exporter is pointed at Beak.

Govern LangChain, ADK and CrewAI agents from inside their own process​

A new POST /aisecurity/hooks/prompt endpoint puts the inference-hook level within reach of middleware Beak does not host: it is the Gateway's own prompt scan, authenticated with a broker token, with the tenant fixed by the token. Alongside it, the beakagenthooks library attaches both hooks — prompt and tool — to LangChain 1.x (middleware), Google ADK (plugin) and CrewAI (execution hooks) in one line each. See The prompt hook and Framework hooks.

  • Same verdict as the Gateway. The prompt hook runs the inline scan unchanged — same policies, same ledger — so a LangChain agent and a Gateway-routed agent are judged alike.
  • Off by default. The library ships in log mode: it records what enforcing would have refused and refuses nothing until you switch to enforce.
  • Two failure policies, stated. With Beak unreachable, a tool check refuses in enforce mode; a prompt check proceeds and alarms. Nothing is silently skipped.
  • Calling earns the level. The first prompt earns inference.hook, the first tool call earns tool.hook; the agent's tier follows what it actually crosses.

Note: Install the extra for your framework (beakagenthooks[langchain], [adk], [crewai]); the core depends on httpx only. A broker token minted under /aisecurity/brokers/tokens and the agent's registry id or BEAKIAM identity are required.

Put Beak on any platform's tool hook — Claude Code, MCP proxies, AgentCore, AGENT-HOOKS​

One receiver, POST /aisecurity/hooks/tool, now accepts the tool-call payload of four shapes — Beak's own frame, Claude Code's PreToolUse hook, a JSON-RPC MCP tools/call (what an MCP proxy or a Bedrock AgentCore Gateway interceptor forwards), and the AGENT-HOOKS-0.1 contract — and answers each in its own reply shape. Previously the tool boundary existed for Copilot Studio alone. See The tool-hook receiver.

  • The same decision for every platform. Tool authorization against the agent's scopes (fails closed), then the tenant's tool policies over the tool inputs and context (fails open with an alarm), then escalation when the agent's profile reserves the tool for a human.
  • Escalation with a resume token. A platform that cannot pause receives escalate and a token to poll; operators see pending approvals and decide them with agents:authorize. Approvals expire after 30 minutes.
  • Claude Code gets deny or ask in its permissionDecision; MCP callers get a JSON-RPC error carrying the reason code; AGENT-HOOKS callers get ALLOW, DENY or ESCALATE.
  • Calling it earns the tool-hook level. Every verified call records the agent as seen at the tool boundary and grants tool.hook, so a Claude Code or AgentCore agent's governance reflects what it actually crosses.

Note: The receiver authenticates with a broker token (bkr_), minted under /aisecurity/brokers/tokens; the tenant comes from the token. It always answers 200 — a refusal is a successful answer — because every one of these platforms runs the tool when a hook returns an error. Copilot Studio's dedicated endpoint is unchanged.

Onboard an agent in seven steps, and see the first governed event arrive​

Agent Registry → Onboard agent now walks an operator from where the agent runs to the first event Beak records for it: pick the platform or framework, choose one of the three integration levels, register the agent with an accountable owner, take the credential the level needs, copy the verified snippet for that framework, and watch for the first governed event. See The onboarding wizard.

  • Only reachable levels can be chosen. A level the framework's own protocol cannot support is disabled with the reason; a level Beak has not shipped the receiving half for is disabled and names the gap. Neither is left blank or greyed without a sentence.
  • An owner is required. Every agent onboarded through the wizard names the accountable person. Agents registered over the API may still omit it for this release; the console labels the absence ("no owner recorded") rather than rendering a blank.
  • Credentials are issued in the flow and shown once — an enrolment token for Full Gateway on an agent Beak does not host, a broker token for a middleware or webhook level.
  • "Onboarded" means observed. The verify step reports the agent as pending integration until Beak records its first event, and renders a coverage ladder with every absent rung labelled.
  • Platform pages link straight into the wizard with the platform already chosen.
  • Discovered agents go through the same steps. Choosing Onboard on a candidate a connector or a hook found no longer adopts it in one click: it continues into the level, register (id and name pre-filled, owner required), result, integrate, verify and mode steps, and the adoption records the owner and declared level with the governance change. A Beak AI Runtime candidate can still be issued its Gateway credential, now from the register step. Exclude is unchanged.

Note: No existing agent changes. The by-hand boundary picker is still available for sources the catalog does not list. A synthetic "send test event" probe is planned alongside the generic tool-hook receiver; today the verify step waits for real traffic.

Three integration levels, a tool-hook boundary, and grants that record themselves​

An agent from any platform now integrates at one of three levels — Full Gateway, Inference hook, or Tool hook — and GET /aisecurity/agents/onboarding-catalog states, per framework and platform, which levels it can reach and how. A level a framework's own protocol cannot support is reported as unreachable with the reason; a level Beak has not shipped the receiving half for is reported as not yet available. Neither is left blank. See Governing an Agent from Any Platform.

  • New boundary tool.hook. The agent's platform asks Beak before running a tool — what Copilot Studio's external threat detection has always done — is now a boundary of its own, distinct from hub.tools, where Beak proxies the call and sees its result. A Copilot Studio agent's brokered tier is now a recorded grant, and any platform that registers Beak as its tool hook earns the same tier the same way.
  • Grants record themselves. A virtual key bound in Beak AI Gateway, an agent-owned MCP connection created in Beak AI Hub, and the first inspected Copilot Studio tool call each record their boundary on the agent's governance profile automatically. The earlier warning that granting was an operator action no longer applies.
  • Agent-owned Hub connections are enforced, not just declared. Every tools/call on a connection owned by an agent identity is authorized against that agent's scopes before Beak AI Hub forwards it. A denial is returned to the MCP client as a JSON-RPC error carrying the reason code. The check fails closed: if Beak AI Security cannot be reached, the call is refused rather than forwarded.
  • External tool dispatchers need a broker token. Callers outside the Beak cluster must present a bkr_ token on /aisecurity/tools/authorize; the token fixes the tenant and the tenantid header is ignored. Operators mint and revoke tokens under /aisecurity/brokers/tokens with agents:keys. Beak's own services are unaffected.

Note: No existing agent's governance changes on upgrade. Copilot Studio agents gain a recorded tool.hook grant on their next inspected call, which leaves their tier where it was. Tool authorization on Hub applies only to agent-owned connections; user and team connections behave as before. Hub's grant reporting is off until an operator sets SECURITY_SERVICE_URL, AGENT_GOV_ENVIRONMENT and AGENT_GOV_WORKLOAD_PRIVATE_KEY_PEM on Beak AI Hub and provisions its public key as a trust anchor in Beak AI Security.

Find the agents on Bedrock, Agentforce, OpenAI and A2A — not just the Microsoft ones​

Beak AI Security and Governance can now enumerate the agents that exist on Amazon Bedrock, Salesforce Agentforce, OpenAI Assistants and A2A, and place them in the Agent Registry before any of them has called Beak. Previously only Copilot Studio (via Power Platform) and Agent 365 could be enumerated, so "what agents exist across my organization" was answerable for the Microsoft stack and silent everywhere else — an agent on Bedrock was invisible until it happened to call.

Each platform is a new card under Integrations → Agent Platforms, configured with its own credential, and Test connection enumerates for real rather than only checking that the credential authenticates. See Integrations.

  • Off by default, and nothing changes on upgrade. No credential is created for you and no discovery runs until an admin configures a platform. Existing integrations, agents and governance are untouched.
  • Discovered agents are candidates, not governed inventory. Every agent found arrives as discovered at the registered tier — inventory and identity only. Nothing is enforced for it until you onboard it, and appearing in a vendor's listing is not a decision to govern the agent.
  • A vendor calling its agent proxied does not raise its tier. All four platforms describe their agents that way as a matter of course. Beak ignores it: the tier is declared from the source, never inferred from how a vendor describes itself, because a tier claimed on a hint is a compliance signal with nothing behind it.
  • A2A is the one platform that needs no secret. An Agent2Agent card may be published without authentication, so the bearer token is optional there and required everywhere else.

What it requires: an AWS principal with bedrock:ListAgents and bedrock:GetAgent; a Salesforce connected app with the api scope; an OpenAI API key; or, for A2A, the base URL of each agent whose card should be read. Credentials are encrypted at rest with the same per-tenant key as every other integration.

Note: Discovery reads a vendor's listing — it does not put Beak on any agent's call path, and it cannot. Tool authorization, prompt and completion inspection and cost attribution still require the agent to route through Beak; see Governing an Agent from Any Platform.

Unified-login sessions no longer expire after 15 minutes​

If you reach Beak AI Security through unified login, your session now lasts as long as your single sign-on session allows — up to 8 hours on a standard tenant — instead of returning you to the login page roughly every 15 minutes. The renewal request was previously rejected by the browser on tenant-branded addresses — your own company domain, or a <tenant>.beakops.com address — so only users on the default product address were unaffected.

On by default; no configuration, and no change to your tenant's session or idle timeouts. A password sign-in on Beak AI Security's own login page is unaffected.

See Platform Administration release notes.

Govern an agent built on any framework, and see exactly what is covered​

An agent written on LangGraph, CrewAI, LangChain.js, Mastra, or nothing in particular can now put itself in your governed inventory with one call at startup, using the new Beak agent SDKs — beakagentidlib for Python, @beak/agent-identity for Node. It then appears in Agent Governance beside the agents you built in Beak. Previously the only ways in were a Runtime connector or an operator enrolling the agent by hand, so a team's own agent had no self-service path at all. See Governing an Agent from Any Platform.

Alongside it, Agent Governance now reports which governance planes actually apply to each agent rather than a single label. Seven planes are tracked — inventory, identity, tool authorization, runtime policy, prompt inspection, completion scanning, and cost — and each one is present only because of a boundary the agent's traffic really crosses.

  • What Beak governs follows the agent's integration, not its paperwork. Completion scanning and cost attribution are available only when model calls route through Beak AI Gateway, because there is no other point at which Beak sees the answer or the bill. Registering, adopting, or reconfiguring an agent cannot produce them.
  • An agent can ask, but only Beak can grant. An agent declares the boundaries it intends to cross; those show as pending and change nothing until Beak issues the credential that makes one real. Without that split an agent could assert its own governance — naming a boundary and having the dashboard report coverage that nothing was performing.
  • A combination that matches no preset is reported as custom, not rounded. An agent holding six of the seven planes is described honestly rather than rounded down to the nearest tier name. Read the capability matrix; a tier badge is a summary and for a custom agent it is one no lookup table can expand.
  • An unrecognised source lands at the floor. An agent whose origin Beak cannot identify is reported as registered — inventory and identity only. The default under-claims on purpose.

Note: Nothing changes for any existing agent on upgrade, and no agent's governance is reduced. The planes each agent already had are the planes it keeps; what is new is that they are stated individually instead of implied by a label. Automatic registration for connector-synced agents is off until an operator sets AGENT_GOVERNANCE_SECURITY_URL on Beak AI Agent Runtime.

Note: Since the entry above, gateway.llm, hub.tools, inference.hook and tool.hook are recorded by the service that observes the boundary being crossed; only registry.only is set by an operator. A pending boundary now means the agent has not yet crossed it, not that someone has to file it — the onboarding wizard's verify step waits for exactly that first crossing.

The audit trail now records who an agent was and how it was acting — and proves it​

A moderation verdict used to record what was decided. It now also records which agent principal the decision was about and whether that agent was acting unattended or under a person's delegated authority — and both are inside the tamper-evident hash chain, not merely stored alongside it. Re-attributing an unattended decision as an interactive one, or re-pointing a verdict at a different agent, breaks verification for every event after it. See Audit Log.

The Mode column on the Execution Ledger shows this per row, and a mode filter splits the ledger into unattended and delegated decisions. The unattended view is the one an incident review wants first: it answers "what did agents do while nobody was watching", which the rest of the trail cannot isolate.

  • The mode is declared when a credential is issued, never inferred from the request. A guessed mode could be re-derived differently later; a declared one is a claim someone made at the time, which is what makes it evidence.
  • Mode and trigger are independent. An agent can act unattended and with a person's delegated authority — a scheduled job carrying a user's authority is a real shape — so a row may show OBO and still name a trigger.
  • The ledger is append-only at the database. Editing the attested columns, the chain, or a row's schema version is refused outright, and so is deleting a row. Reviewer annotations stay editable, because those were never part of the attested claim.
  • Concurrent verdicts no longer collide. Bursts of simultaneous scans in one tenant each take a distinct position in the chain; previously they could share one, which made an intact chain report itself as broken.

Note: Nothing about enforcement changes. This is what gets recorded about a decision and how hard it is to alter afterwards.

See how many decisions were never inspected​

Content inspection is deliberately fail-open: if the policy store is unreachable, requests proceed rather than every agent in the tenant halting. Until now that was invisible — such a decision is reported as allowed and compliant, indistinguishable on the wire from a clean pass and from a tenant with no policies configured.

Agent Governance now shows a running count of decisions that proceeded without policy inspection, and an Uninspected only filter on the Execution Ledger opens the decisions behind that number.

Warning: An uninspected decision is not a checked one. The request was not blocked, but no guardrail was applied to that traffic.

  • The count reads zero when it should. If inspection has held, the panel says so plainly rather than showing an empty widget.
  • A failed count says "unavailable", never zero. Reporting no uninspected decisions because the query itself failed would be the same class of silence this exists to correct.
  • It composes with the mode filter, so "unattended and uninspected" is a single question.

Bring an agent Beak didn't build under Beak governance​

An AI agent running somewhere else — Amazon Bedrock, Microsoft Copilot Studio, Salesforce Agentforce, an A2A peer, or a script you host yourself — can now become a governed principal in your tenant. It gets a Beak identity, appears alongside your own agents in Agent Governance, and is subject to the same policies, autonomy grants, and audit trail. Previously an external agent could be seen in the Agent Registry and governed at the tool boundary, but it could not hold a Beak identity at all — so it could not be given a credential, an autonomy grant, or its own line in the audit log. See Agent Governance.

A new Enrolment tab is where you do it. You mint a single-use token naming the agent, its accountable owner, its scope ceiling and where it came from; the agent presents that token with proof it holds its own signing key. Beak stores only the public half — no part of Beak ever holds an external agent's private key.

Warning: The token is shown once. Beak stores only a hash, so it cannot be retrieved later — copy it before closing the dialog. It is single-use, and minting or revoking one needs agents:authorize, the same permission as granting autonomy.

  • An enrolled agent holds identity, not authority — immediately after enrolling it can prove who it is and nothing else. A credential request is refused until a human grants it autonomy from the Identities tab. That is the same rule every agent built in Beak already lives under: where an agent came from is recorded as provenance, and does not change how much it is trusted.
  • Every token is kept, including used and revoked ones — because "which person authorised this agent to exist, and when" is an audit question. A consumed token links to the identity it produced. Revoke is offered only on a token nobody has used yet; if the agent has already enrolled, revoke the identity instead.
  • Provenance on every identity — the identity detail now shows where an agent came from, whether it holds its own signing key, its id in its own platform, and its key fingerprint and validity window. None of this was visible before.
  • Search, filter, sort and export across the whole tenant — not just the page on screen, on both the Enrolment and Identities tabs.

Note: Nothing changes for any existing agent on upgrade. Agents built in Beak keep registering their identity automatically, and no external agent is enrolled until someone mints a token for it — there is no bulk import, because enrolling an agent is a decision a person makes about one agent at a time. Agents already discovered through Power Platform or Agent 365 stay exactly as they are: still governed, still not principals, until you enrol them.

Integrations have their own menu, grouped by what they do​

Connectors are no longer a tab inside Settings. Administration → Integrations is now a catalog of all nine — Anthropic inference hooks, Microsoft Copilot Studio, Power Platform, Agent 365, Defender XDR, Sentinel, Defender for Cloud Apps, Purview and Teams — each with its vendor's logo, a one-line description of what it does, and its current connection state on the card. Previously they were one long scroll under Settings → Integrations, which you could only use if you already knew what was in it. See Integrations.

  • Grouped two ways — By type groups by outcome (AI Platforms, Agent Platforms, Security Operations, Data Governance, Notifications), so you can find the connector that forwards blocks to a SIEM without knowing it is called Sentinel. By vendor groups by provider, to see everything Beak does with one vendor's stack. Both show the same nine integrations.
  • Search across the catalog — Matches an integration's name, vendor, group and description, so searching audit finds Microsoft Sentinel.
  • Connection state on the card — Connected, Disabled or Not connected, read live per integration. Disabled means a credential is stored and the integration is switched off — the state to look for when something that used to dispatch has gone quiet. When the state cannot be read, the card shows nothing rather than claiming Not connected.
  • One page per integration — Selecting a card opens that integration's configuration on its own page, with a link to the screen its data feeds — the Agent Registry for Power Platform, Incidents for Defender XDR, the Audit Log for Sentinel.

Note: Nothing changes about any configured integration on upgrade — the same credentials, the same dispatch, the same permissions (integrations:read to view, integrations:update to save). Existing links to Settings → Integrations redirect to the new page, so bookmarks and links in other screens keep working. The menu appears for anyone holding either integrations:read or settings:read, because the connectors behind it are enforced with both — so no administrator who could configure an integration before the move loses their path to it. Cards you cannot configure are hidden.

Find and onboard agents from Security, and see what actually enforces for each one​

You can now discover Copilot Studio agents and adopt them without leaving Beak AI Security, and every agent in the registry states what is enforcing for it. Previously the registry showed only agents someone had already adopted, and it did not distinguish an agent whose prompts Beak inspects from one where Beak is called at the tool boundary alone.

The new Coverage column names that difference: Inference when the agent's model calls travel through Beak and its prompts and completions are inspected; Tool hook only when Copilot Studio's external security calls Beak for tool executions and nothing else — the agent runs in Microsoft's cloud and its conversations never reach Beak; Observed only when the agent is in the inventory and nothing enforces for it. Filter by coverage to find the third group. See Agent Registry.

Warning: Onboarding an agent does not change its coverage, and adopting a Tool hook only agent does not begin inspecting its prompts. Coverage follows how the agent reaches Beak, so reaching Inference is a change to how the agent is deployed rather than a setting. Beak marks coverage only from a path it has actually been called on, so an agent listed in Power Platform reads Observed only until it calls.

  • Discover agents — A new action on the registry enumerates Copilot Studio agents from your Power Platform environments, so they appear before any of them has called Beak. Everything found arrives as a candidate: Discovered, Inactive, no scopes. An agent that is not Governed cannot authenticate, so discovery never authorizes anything on its own.
  • Onboard and Exclude — Candidates can now be adopted or excluded from the registry. Excluding is durable — a later sync that still reports the agent will not bring it back. Onboarding needs agents:create, the same permission as adopting an Agent 365 agent; excluding needs agents:update.
  • Power Platform integration — A new integration under Integrations holds the credential discovery uses. It is separate from Copilot Studio threat detection and neither replaces the other: threat detection is inbound and enforces, Power Platform is outbound and finds. Test connection lists bots in each environment you name rather than only exchanging a token, because an app can obtain a token and still be refused by every environment.
  • The Governance filter now works — The registry sent the filter and the server ignored it, so Discovered agents could not be listed at all. Candidates were reachable only through the Agent 365 pages.

Note: Off by default in the sense that nothing changes until you configure Power Platform — discovery has no credential until then. Existing agents are unaffected on upgrade, and their coverage is set only where there is evidence: agents Beak runs and Anthropic hook configurations read Inference, Copilot Studio agents that had already called Beak read Tool hook only, and everything else reads Observed only until a path is confirmed. Nothing is marked as covered on the strength of what an external platform reports.

Incidents now cover every source, not only browser scans​

The Incidents page listed browser-extension scans only. Policy hits from Microsoft Copilot Studio, Anthropic and the moderation API were decided by the same rule engine but could not be shown on the page. All four sources now appear together, separated by a new Origin dimension — Endpoint for a person at a managed device, Agent for a model or agent calling in — with a Detected by filter for the specific integration. See Incidents.

Note: Anthropic verdicts were affected more seriously. A denied prompt could not be written to the audit trail at all, so no denied Anthropic request appears in incidents recorded before this release. Allowed verdicts were stored normally. Denials from this release onward are recorded in full; earlier ones cannot be recovered, because they were never written.

  • Paginated and filterable — The page now pages through the whole result set instead of showing the first fifty rows, and the item count is the server's total for the current filters. Search, Origin, Detected by, Action and the time range are all resolved server-side, so they cover every incident in range rather than the rows on screen. Search also reaches the policy name, the surface, the agent identity, and a Copilot tool call's arguments.
  • Readable columns — Sources read as Microsoft Copilot Studio and Anthropic rather than internal identifiers, the policy that fired is named rather than numbered, and a shadow-mode verdict renders as Would block in amber instead of sharing the neutral styling of allowed traffic.
  • Only policy hits by default — Requests that no policy acted on are excluded, so the count reflects what your policies stopped. Include allowed widens the list.
  • Request details in the drawer — For a Copilot Studio incident the drawer now shows the tool that was called and the arguments it was called with; for an Anthropic incident, the model, actor and session. This detail was recorded previously but never displayed.
  • Links to external incidents — A new External systems section shows where the incident was mirrored. Microsoft Defender XDR carries a direct link to the created alert; Microsoft Sentinel shows a ready-to-run KQL query that locates the incident in the Log Analytics table, because batched ingestion returns no per-incident identifier to link to; Microsoft Teams shows delivery status. Failed dispatches surface their error.

Note: Teams notifications and Sentinel forwarding could not record their state before this release — the tables they depend on were missing — so no Teams notification was delivered and no audit row reached Log Analytics on any earlier version. Both now work; forwarding begins from the point of upgrade and does not backfill. Configure them in Integrations.

Reading the page requires the incidents:read permission, which every built-in read role already carries.

Version 1.0.0​

  • Support for LLM scanning and policy-based prompts.