Shield360 › For AI governance
An agent is a principal.
Govern it like one.
Agents read repositories, call tools and act on systems under somebody's authority. For the people who answer for that — risk, security, compliance and legal — governing them comes down to six questions. This page states each one, what Shield360 records towards the answer today, and where that record stops.
01 · Overview
Six questions
Six pillars, and the question
each one has to answer.
A governance framework that cannot be checked against a record is a statement of intent. So each pillar below is written as the question a reviewer will actually ask, followed by what Shield360 shows today. They are not equally deep, and the page does not pretend otherwise: where the record stops, it says so.
| Pillar | The question | Assessment area |
|---|---|---|
| Inventory | Which agents and AI tools are running, where, and for whom? | Visibility |
| Identity | Which agent did this, with whose credential, under whose authority? | Keys and access |
| Controls | What is an agent allowed to do, and what is stopped rather than recorded? | Data protection |
| Evidence | Could we show it to an auditor, a regulator or a court? | Audit and evidence |
| Risk | Which activity carries risk, and which framework control does it speak to? | — |
| Operating model | Who owns this, and who is allowed to see what? | Policy and ownership |
The five-minute assessment scores the same ground from what you declare. Its sixth area, cost and attribution, runs through Inventory and Identity here: a key with spend and no owner is a problem for both.
02 · Inventory
What is running
Nobody can govern an agent
that nobody has listed.
The question: which agents and AI tools are in use — the ones your teams built, the ones you bought, and the ones somebody installed on a Tuesday — and on whose machine? An inventory built from a survey is out of date the week it is written.
What Shield360 shows today
One AI inventory
Compliance › AI inventory lists every AI tool, model, vendor, provider key, agent and MCP server seen in use, with the people and computers using it and the evidence for each. Your team records an owner, a purpose, a risk rating and a decision, which can carry conditions and an expiry.
AI requests
The front door to the inventory. Anyone can ask to use an AI tool, model, agent, MCP server or vendor; a reviewer approves it with an owner, conditions and an expiry, or rejects it with a reason, and the decision lands on the inventory.
Personal accounts
The collector reads which account each AI tool is signed in to, so company work done on a Claude Max, ChatGPT Plus or Cursor Pro account is told apart from a company seat.
The Agents screen
Instrumented services and coding agents, on two tabs of one screen. Coding agents — Claude Code, Cursor and Codex — report through hooks installed into the agent itself, so each session is attributed to a person and a machine.
Workloads nobody instrumented
The optional controller discovers LLM workloads already running and can inject the SDK into them, so an application that was never instrumented still appears.
Shadow AI
AI in use that nobody tracks centrally, decided per vendor and per person: a paid plan no company seat covers, per-token spend on a key that may not be the company's, time on AI websites and desktop applications, and processes talking to an AI provider directly. Use is treated as sanctioned where the person holds a seat from that vendor, so what remains is worth a look. Network and browsing evidence are off until enabled.
Seats you already pay for
Seat lists for GitHub Copilot, ChatGPT Enterprise and Cursor, read from each vendor's own admin API — who holds a seat, on which plan.
Where it stops. The inventory holds what Shield360 can see. AI used on a machine without the collector, or in an application that sends no traces, does not appear until somebody asks for it. Coding agents that send traces report how many people used them, not who.
03 · Identity
Whose authority
“Which agent did this?”
needs a better answer than a shared key.
The question: when an agent acts, can you name it, name the credential it used, and name the person who allowed it? An agent running on a borrowed key is an unauditable principal: you can see what the key did, not which agent did it.
What Shield360 shows today
Its own token
Each agent that uses the MCP gateway holds its own token, shown once when the agent is created. Shield360 keeps only a hash of it, so a database read never yields a working credential.
Grants, deny by default
An agent reaches an MCP service — optionally narrowed to named tools — a document source narrowed to folders, or a context, only when granted. A grant can carry an expiry; an expired or revoked grant stops applying on the next call.
What it did with them
The gateway records what each agent searched for and called, with the outcome, including refusals. It records names, outcomes, sizes and timings — never the arguments or results, which carry the very data the record exists to account for.
Keys with no owner
Spend on each provider API key is attributed to the owner the vendor names, or to the people and machines seen using it. A key with neither is shown as unattributed, and spend the vendor reports against no key at all is shown separately.
The people behind them
Sign-in federates to your own OIDC issuer, using the authorization code flow with PKCE, so the person who granted an agent its access is a person your directory knows.
Where it stops. A gateway identity covers agents that go through the gateway. An agent that calls a provider or a tool directly is visible by the key or process it uses, not by a gateway identity. Shield360 does not flag provider API keys by age or disuse.
04 · Controls
Stopped, not only recorded
A control that only records
is a log.
The question: what is an agent allowed to do, and where is that enforced rather than written down? Shield360 prevents where it is genuinely in a position to — the browser extension, the coding-agent hooks, the MCP gateway and, for applications routed through it, the optional AI proxy — and observes everywhere else.
What Shield360 shows today
| Control | Where it acts | What happens |
|---|---|---|
| Sensitive data | The browser extension in managed Chrome and Edge, the optional AI proxy, and inside coding agents, before anything leaves | One organization-wide policy, per kind of data and per channel: off, warn, mask or block, and an environment can override any setting. Coding agents warn or block, and files that hold secrets — .env, private keys — can be stopped from being read. An organization can require a machine, browser or proxy that cannot read its policy to refuse rather than allow. |
| AI tools and models | The browser extension and the AI proxy | Allow, warn or block per AI tool. A request for a model outside the environment's approved list is warned on or refused at the proxy. |
| The order of agent actions | Coding-agent hooks and the MCP gateway | Sequence policies, such as a secret read followed by a network call, enforced live and checked again afterwards over traces. |
| Agent access to tools and data | The MCP gateway | Deny by default. Nothing is reachable that was not granted to that agent. |
| Who may change a control | Every server route | Roles and permissions are checked on the server, not only in the interface. A refusal is recorded as a denied event in the audit log. |
The compliance overview states the current mode in words beside its counts, so a zero is never mistaken for protection when the control is set to warn.
Where it stops. Shield360 does not intercept TLS. AI use that does not pass through the extension, the AI proxy, a coding-agent hook or the gateway is recorded, not stopped. Coding-agent hooks do not yet enforce the approved-model list, and nothing is enforced per person.
05 · Evidence
What survives an audit
Evidence is a record
nobody could have edited.
The question: if an auditor, a regulator or opposing counsel asked what an agent did and who looked at it, could you hand over a file — and show it had not been touched? This is the deepest of the six.
What Shield360 shows today
An append-only audit log
Changes, reads of sensitive data, sign-ins including failed ones, and denied requests, each with an actor, a target, an outcome and a source address. The database itself refuses any update or delete on the table, so a bug, a script or a stray query cannot rewrite it. The one path that removes records is deleting the organization entirely.
Secrets kept out of it
Request bodies are never recorded, and metadata fields named like passwords, tokens, API keys, cookies or credentials are dropped before a record is written.
Control status, kept daily
Compliance › Controls shows each control of ISO/IEC 42001 (all 38 Annex A controls, each with a Statement of Applicability entry), the EU AI Act, NIST AI RMF and the OWASP Top 10 for Agentic Applications as met, gap or no evidence from what was observed, and keeps the result as a daily history.
A signed evidence package
One file per environment, framework and period: the Statement of Applicability, control status and history, the risk register, findings, internal audits, management reviews, an inventory summary and the policy in force, with a readable report as HTML and PDF. Its manifest is signed with Ed25519, so an auditor can verify it offline without trusting Shield360, and auditor access gives them read-only access to the same evidence until a date you choose.
Exports
The audit log and data protection events export as CSV for any window and filter, and each export is itself recorded. Any single trace downloads as a governance report in JSON: its findings, risk level and mapped framework controls.
Retention and legal hold
A retention horizon per record type, stated on the compliance overview, and a legal hold that preserves named custodians' records past every horizon until it is released with a reason. The compliance page lists each horizon.
Where it stops. An evidence package is evidence for an auditor to examine, not a certification or an audit opinion. The Statement of Applicability records what your team decided and attested; Shield360 does not judge whether the evidence you point to is adequate.
06 · Risk
Raised from what ran
Risk is raised from what ran,
not from a workshop.
The question: which agent activity carries risk, how serious is it, and which control in the framework you report against does it bear on?
What Shield360 shows today
A risk register that fills itself
Risks are raised every hour from what was observed — sensitive data sent after a warning, a rejected tool still in use, an unapproved model, prompt injection, an agent breaking a sequence policy or holding access it does not use — scored by likelihood and impact, and linked to their evidence. Accepting a risk needs a rationale and an expiry; when the acceptance runs out, the risk reopens and an alert is raised.
A score on every AI asset
Each inventory asset carries a risk score from 0 to 100, from its approval status and what was observed, and an alert fires when it crosses the threshold you set.
Impact assessments
Each AI system's impact on people and society, assessed from what Shield360 observed, with the judgment and sign-off recorded and every version kept.
Findings on a trace
Opening a trace's governance view produces findings from the trace itself — errors, agent loops, unhealthy generations, bursts of tool calls, the permission mode a coding agent ran in — and from any evaluations run on it. Each finding carries a severity and a suggested remediation.
A risk level
The trace's risk level is its most severe finding: info, minor, major or critical.
Mapped to framework controls
Findings are mapped to controls in the NIST AI Risk Management Framework, the EU AI Act and the OWASP Top 10 for Agentic Applications, so a reviewer can see which control a finding speaks to.
A mapping is not compliance. Mapping a finding to an article or a control says what the evidence is relevant to. It is not a legal determination, Shield360 is not itself a certification, and it should not be described as one in a questionnaire response.
Where it stops. The register reads the last 30 days of violations and the inventory's 90-day lookback, so older behavior does not raise a risk. A trace's own findings are assessed when somebody opens it.
07 · Operating model
Who owns it
Governance is somebody's job.
The tool has to fit the job.
The question: who owns AI governance, what can each office see, and can the people who review the record be kept from changing it?
What Shield360 shows today
Boundaries
Organization, project and environment are enforced boundaries. Security, finance and compliance read one deployment and one dataset, each through its own role.
Seven system roles
Owner, Administrator, Compliance officer, Analyst, Member, Viewer and Auditor. The Compliance officer keeps the compliance records — inventory decisions, AI requests, the risk register, the Statement of Applicability, findings, audits, impact assessments and legal holds — and can read but not change the enforcement policy. An Auditor is an external person who reads one environment's evidence, and nothing else, until a date you choose.
Custom roles
An organization can define its own roles from the permission catalog, where each permission is described in the words an administrator reads when assembling one. A member can hold a different role in each project.
A second person
Transports move prompt versions, the approved-model list and enforcement settings from one environment to another only once a second person approves, with a diff, a release log and rollback.
The management system
Findings tracked from containment to a reviewed correction, internal audits that check the lead auditor's independence, and management reviews with an input pack drawn from Shield360's records — as ISO/IEC 42001 clauses 10.2, 9.2 and 9.3 ask.
Where it stops. Organization-wide permissions — members and roles, billing, the audit log, alerting — always come from the organization role; a project role cannot grant them.
08 · Bought, not built
Third-party agents
The agents you bought
are governed differently.
Most agents in a company were not built there. They arrive as a seat — Copilot, ChatGPT Enterprise, Cursor, Claude Code — and a vendor's console reports on its own product and nothing else. The rule for them is the same as everywhere on this site: where Shield360 is inside the tool, it can stop something; where it reads a vendor's admin API, it can say who holds a seat, not what the assistant did.
| Tool | What Shield360 reads | What it can stop |
|---|---|---|
| Claude Code | Sessions per person and machine, through hooks in the agent | Sensitive data and secret files: off, warn or block |
| Cursor | Sessions through hooks, as above; members and spend from the Cursor Admin API | Sensitive data and secret files: off, warn or block |
| GitHub Copilot | The seat list from GitHub's billing API: who holds a seat, on which plan | Nothing — Shield360 is not in its path |
| ChatGPT Enterprise | The seat list through OpenAI's Enterprise Compliance API, where the workspace has it enabled | Nothing through the API; on the web in a managed browser, as for AI chat sites below |
| AI chat sites | Use per person, through the browser extension in managed Chrome and Edge | Sensitive data: warn, mask or block. The tool itself: allow, warn or block |
| Anything else | Shadow AI evidence: paid plans, AI websites and apps, direct connections | Nothing — discovered and reported, not blocked |
A seat list is still worth having: it is what lets shadow AI discovery treat a person's use of a vendor as sanctioned, so that what is left over is the use nobody bought.
09 · The role
The AI governance lead
One person now answers
all six questions.
Some organizations now hand AI governance to one named person — often from risk, security or legal — rather than split between three offices. That person does not need another dashboard. They need read access to the record behind each pillar, and no ability to change how the platform runs, so that what they review is not something they could have arranged.
| Pillar | Where they look in Shield360 |
|---|---|
| Inventory | Compliance › AI inventory and AI requests; Agents; Visibility; Costs › Shadow AI and subscriptions |
| Identity | Agent Access: agents, grants and activity; Costs › API keys; Visibility › AI accounts |
| Controls | Compliance › Policies, Data protection and Prompt injection; the Overview, which states the guard mode in words |
| Evidence | Compliance › Controls and the evidence package; Audit log, Legal holds, Data protection export |
| Risk | Compliance › Risk register and Impact assessments; a trace's governance view and its JSON export |
| Operating model | Settings › Team, and the roles defined there; Compliance › Transports, Findings, Internal audits, Management review |
There is no role called governance lead in Shield360. The nearest system role is Compliance officer. Where the job spans more than compliance — agent grants, spend by key — an organization can assemble a custom role from the permission catalog.
10 · Questions
Asked by reviewers
What a reviewer asks.
Does Shield360 make us compliant with the EU AI Act?
No. It gives each of the 33 Articles that place obligations on organizations that build or use AI a status — met, gap or no evidence — from what was observed and what your people attest, keeps a serious-incident register, AI literacy records and fundamental rights impact assessments, and maps findings on individual traces to articles of the Act and to NIST AI RMF and OWASP controls, which tells a reviewer what the evidence is relevant to. Whether an obligation is met is a determination for you and your counsel.
Is this a certification?
No, and it should not be described as one. Shield360 produces the evidence an auditor asks for — control status, an audit log, enforced retention, holds and signed evidence packages. The attestation is still yours to obtain.
How quickly can an agent be cut off?
For an agent that uses the gateway, revoke its grant, or let the expiry pass: the next call is refused, and the refusal is recorded. An agent holding a provider key directly is cut off by revoking that key at the provider.
Is there one inventory of every agent?
Yes. Compliance › AI inventory lists every AI tool, model, vendor, key, agent and MCP server seen in use, built from observation rather than a survey, with the owner, purpose and decision your team records. It holds what Shield360 can see; AI on a machine without the collector does not appear until somebody asks for it.
Can the person reviewing the record change it?
Not the audit log: no role can edit it, because the database refuses it. An Auditor reads one environment's evidence and changes nothing. The Compliance officer keeps the compliance records but cannot change the enforcement policy or what is collected.
Find your weakest pillar first.
The assessment asks eighteen questions across six areas and scores them in your browser. It takes five minutes, needs no sign-up, and your answers stay in your browser.