Saltar al contenido principal

Agent Passport

The Agent Passport is the full record of a single agent. Open it by clicking any row in the Agent Registry, or the eye icon on that row.

Before it existed, an agent's detail was spread across four separate panels on four different screens — the registry's own dialog, the risk score sheet, the agent governance identity sheet and the Microsoft Agent 365 detail sheet — with spend, audit and supply-chain information elsewhere again. The passport brings them together so a review, an incident, or an auditor's question can be answered from one page.

It answers seven questions, in this order.

SectionThe question it answers
WhoWhich agent is this, and who is accountable for it?
WhatWhat is it for, and what can it actually reach?
WhereWhich tenant, environment and platform does it operate in?
What authorityWhat is it permitted to do, and how far unattended?
How riskyWhat has Beak measured, and what has it not?
How longUntil when is this agent approved, and when was it last active?
What happenedWhat has it done, and what was decided about it?

Two things to know before reading a passport​

These two conventions are what make the page usable as evidence rather than as a summary.

"Not recorded" means nobody has filled it in​

Where Beak holds no value for a field, the passport says so in words instead of leaving the space blank. This is deliberate: a blank field reads as "there is nothing to record here", when the truth is usually "nobody has recorded this yet" — which is a governance gap somebody can close.

Several fields are operator-entered and empty on every existing agent until someone fills them in, because nothing in the platform can discover them: business owner, sponsor, developer, environment and geography. Newly registered agents can carry them from the start; agents that were discovered by a sync cannot.

The page is equally careful in the other direction. Each of these is a different answer and reads differently:

  • Not recorded — the field exists and is empty.
  • Not enrolled — this agent has no Beak identity. For an agent from an external estate that is correct and permanent, not a gap.
  • No autonomy has been granted — a real governance state, not missing paperwork.
  • Agent governance is unavailable — Beak could not reach the identity service, so its autonomy is unknown. Not the same as having none.
  • Cannot be measured — this agent carries no identifier that recorded traffic is attributed to, so its activity cannot be counted at all. That is itself worth investigating.
  • Requires audits:read — your account cannot see this section. Nothing here implies the agent has been inactive.

Declared is shown beside observed, never merged​

In the What section every capability appears twice:

  • Declared — what the system that registered the agent said it has. A claim. It grants nothing, and no enforcement path consults it.
  • Observed — what the agent's own recorded traffic proves it used, over the stated window.

They are never combined, because the gap between them is the interesting part. A tool that is declared and never used is dead configuration. A tool that is used and never declared is an agent doing something nobody wrote down.

Observed values come from Beak's audit records, which are hash-chained and append-only — so they are evidence, not a separately-maintained list that could drift.

Who​

FieldSource
Registry agent IDBeak's own identifier for the agent
BEAKIAM identityThe agent's cross-platform principal. Absent for agents from external estates, permanently and legitimately
Estate IDThe identifier the source estate knows it by — for example an Entra service principal object ID
Platform IDThe identifier in the originating platform, such as a Copilot Studio bot ID
Operational ownerWho is paged when this agent misbehaves
Business ownerWho is accountable for it existing at all
SponsorWho carries the budget and the mandate
DeveloperWho to ask what it actually does
PlatformThe estate it came from
HostingWhether Beak, the customer, or a vendor runs it

Four accountable people, not four spellings of one. In practice they are frequently different people, and each answers a question the others cannot. All four are free text — an email or a name — because the accountable human for an external agent is often not a Beak user at all.

The section ends with the agent's cryptographic identity: key status, algorithm, fingerprint and creation date, plus Generate, Rotate and Revoke where your account holds agents:keys. Seeing the key state needs only read access; changing it does not.

Warning: A generated or rotated private key is shown once. Copy it before closing the dialog — Beak does not retain it and no later request can return it. If it is lost, rotate the key to issue a new one.

What​

Purpose, then each capability dimension as declared-beside-observed: models, tools, MCP servers, data, external APIs and other agents. Below that, the tool rules that actually decide access — tools explicitly allowed, explicitly denied, and those requiring human approval — and finally what governance can reach for this agent at its tier.

Three limits are stated on the page itself and are worth repeating here:

  • Observed data shows the class of surface a call crossed, not which datasource. Beak records that an agent touched a datasource-class surface; it does not hold a per-agent datasource list.
  • Beak does not observe external API calls. Only declared values appear for that row.
  • Observed "other agents" shows what triggered this agent — per-call causation. It is not a declared relationship graph, and an agent appearing there is a caller, not a sub-agent.

A long list is capped, and a capped list says so rather than appearing complete.

Where​

Tenant, environment, geography and platform.

Environment is the Beak deployment tier — dev, qa, uat or prod. It is a different thing from hosting in the Who section, which says who runs the agent rather than which tier it belongs to. Geography is free text so it can hold whatever actually answers the residency question for you: an Azure or AWS region, a country, or a bloc such as "EU".

Beak never infers either one. A platform connector's configured region belongs to your integration credential, not to the agents it discovered, and copying it here would assert a residency fact Beak has not established.

What authority​

Registry scopes, attestation requirement, risk threshold, and the boundaries this agent may cross — again split into declared (what it asked for) and granted (what Beak has actually issued a credential for). Declaring a boundary grants nothing; only issuance does.

Then the autonomy ceiling, read from agent governance: the most this agent may do unattended, what may set it running without a person, the justification recorded when it was granted, and by whom.

Autonomy is held by a principal, so an agent with no Beak identity cannot be granted any — the page says that rather than reporting an empty ceiling.

How risky​

The score, its band, and the six factors behind it: policy violations, Entra risk, attribute probing, red team, reliability and configuration posture. A factor with no evidence behind it is shown as unavailable, never as a zero — for red team in particular, "attacked and held" and "never attacked" are opposite findings and must not look alike.

Note: What this score does not measure. The risk model is built from six sources of evidence, and it is not a five-category assessment of security, data, compliance, operational and financial risk. Specifically:

  • Data risk has no dedicated factor. PII and data-exposure findings reach the score only anonymously, inside the policy-violations aggregate.
  • Financial risk is not an input. Spend is governed by the AI Gateway and reported there.
  • Operational risk is represented by the reliability factor, which currently has no source writing to it — so it measures zero for every agent. Read that as unmeasured, not as clean.
  • Compliance is assessed for the tenant as a whole on the Compliance Dashboard, not per agent.

The passport states all of this on screen. A governance number nobody can decompose is not defensible evidence, and one that quietly omits a dimension is worse.

How long​

Two sets of dates that are easy to confuse, so the passport labels both.

The agent's registration, always readable and present for every source:

FieldMeaning
Approved atWhen a human accepted this agent into the estate. Stamped by Beak when the agent is adopted, and never supplied by a caller, so an approval cannot be backdated. It is not the registration date — a discovered candidate is created by a sync nobody approved
Expires atWhen this registration stops being valid
Review byWhen it is next due for review
Registered at, Profile updated, Signing key createdTimestamps Beak records automatically
Last activityThe most recent recorded call, across all history rather than the display window — an agent dormant for six months must not read as one that has never run

The autonomy grant's own expiry and review appear separately beneath, when a grant exists. They govern one grant, not the agent.

An expiry or review date that has passed is highlighted, and one falling due soon is flagged.

Note: These dates are recorded, not yet enforced. Nothing in Beak currently refuses an agent because its registration has expired — the passport surfaces the date so a review can act on it. Enforcement is a separate change with its own rollout, because every existing agent has no expiry recorded and turning it on would refuse them all.

What happened​

Decision counts for the window, broken down by outcome and by surface; the most recent governance decisions; and the agent's recent action log. Full audit log links to the complete history filtered to this agent.

Note: Human overrides are not recorded per agent. Beak holds no per-agent override history. The only first-class human decisions on an agent's traffic are tool-call approvals, reachable from the review queue; reviews recorded against an individual audit entry are stored on that entry and cannot yet be listed per agent. The passport says so rather than omitting the heading and leaving you to assume overrides are covered.

Exporting a passport​

CSV and PDF buttons in the header export the whole record — every section, every field — for an audit pack or a ticket. Each format takes the shape its reader needs:

  • PDF is the passport as a document: the same seven sections in the same order, each field listed under its heading. It is meant to be recognisable as the page it came from when someone opens it attached to a ticket.
  • CSV is one row per field, with the section as a column, so it can be filtered and sorted in a spreadsheet.

Both carry the same Not recorded wording the screen shows, and both are generated from the same values, so they cannot disagree. That wording matters most in the CSV: a blank spreadsheet cell has no column header to qualify it, and would lose the distinction entirely.

Permissions​

The passport spans several independently-granted permissions, and a section you cannot read is absent with a stated reason rather than failing the page.

SectionNeeds
Opening the passport at allagents:read
Key generate / rotate / revokeagents:keys
Observed capabilities, activity counts, last activity, recent decisionsaudits:read
Autonomy ceilingaudits:read, and agent governance configured for the environment

An account holding agents:read but not audits:read sees the whole identity, capability, placement and authority record, with the evidence sections marked as unavailable.

Best Practices​

  • Fill in the accountability fields when you adopt an agent, not later. Business owner, sponsor and developer are empty until somebody sets them, and an agent nobody is accountable for is the one you least want to discover during an incident.
  • Record an Expires at and a Review by on every agent you adopt. Neither is enforced yet, so the date is only useful if a person is reading it — put both on your review calendar rather than relying on the platform to stop an agent.
  • Treat a gap between declared and observed as a finding, not noise. A tool observed but never declared means the agent is doing something nobody wrote down; a tool declared but never observed is usually dead configuration worth removing.
  • Read governance_tier and coverage together. managed with Observed only means full governance is available for this agent and none of it is applying — its model calls are probably not traversing the Gateway.
  • Check Last activity before suspending or deleting. An agent that has never been observed may simply be unattributable rather than idle; the passport distinguishes the two, and only one of them is safe to switch off.
  • Export the passport when you escalate. The CSV or PDF carries the same Not recorded wording as the screen, so a ticket or audit pack does not silently lose the distinction between an empty field and a measured zero.
  • Do not read the risk score as a five-category assessment. Data and financial risk are not inputs, and the reliability factor currently measures zero for every agent — see Agent Risk Score for what the number is actually built from.