AI requests and approvals

Overview

Govern → Compliance program → AI requests (/compliance/ai-requests) is the front door to the AI inventory. Anyone in the organisation can ask to use an AI tool, model, MCP server, agent, vendor or AI application. A reviewer then approves the request with a risk rating, an owner, conditions and an expiry, or rejects it with a reason. Approving or rejecting records the decision through the inventory’s own decision code, so you do not need to update the inventory by hand.

Each request records:

• What is requested: its type, its name, the vendor and, when the inventory has already seen it, its asset key (for example tool:cursor or model:gpt-4o).
• Why: the purpose, the use case and a justification.
• For whom: the teams or groups who would use it.
• Which data: the kinds of sensitive data involved, chosen from the kinds the enforcement policy protects: api_key, private_key, password, connection_string, ssn, payment_card, token, cloud_credential, email, phone, iban and ip_address.
• For how long: the requested duration, from 1 to 366 days (90 by default).

A request belongs to one environment, the one you have selected. To open a request directly, use /compliance/ai-requests?request=<id>.

Caution

AI requests are a record of your organisation’s decisions. They are not a certification or an audit opinion. A reviewer’s approval is only as good as the review behind it.

Who can do what

Permission	Allows	Held by
intake.read (View AI requests)	See your own requests. With intake.manage or compliance.read, see every request in the environment.	Every role, and Auditors
intake.submit (Request AI tools)	Submit a request, change it while it waits, answer a reviewer’s question and withdraw it	Every member role
intake.manage (Review AI requests)	Start a review, ask for more information, approve or reject	Owners, administrators and the Compliance officer role

The server checks every permission. The page only hides the actions you cannot take.

Submit a request

Open Govern → Compliance program → AI requests and select New request

Choose what you are asking for and enter its name. A model needs its vendor, because a model is approved on the list under its provider.

Describe the need

Enter the purpose, use case, who would use it and why. Choose the kinds of sensitive data involved and how many days you need it for.

Answer the prohibited-practice screening

Answer yes or no to each of the eight EU AI Act Art. 5(1)(a)–(h) questions for the intended use. Every question must be answered. A yes flags a prohibited practice: the request can still be submitted and rejected, but a reviewer cannot approve it. Microsoft Copilot and the Office add-in ask the same questions (see Requests from Microsoft Copilot and the Office add-in). See EU AI Act.

Submit

The request waits for a reviewer, and reviewers get an intake.submitted alert.

Requests from Microsoft Copilot and the Office add-in

People can also file a request without opening Shield360: from the Shield360 agent in Microsoft 365 Copilot (Request access) and from the Office add-in (Request approval on its Procedures tab). Both ask the eight screening questions in the same words and order as the form, because the questions come from Shield360 itself. Shield360 checks the answers exactly as it checks the form’s:

What the channel sends	What happens	What the person is told
All eight answers, all no	The request is filed and waits for review.	Filed for review, with a link to the request.
All eight answers, at least one yes	The request is recorded, flagged, and cannot be approved. A reviewer can reject it.	It cannot be approved, and which practices were flagged.
Some answers, or an answer that is not yes or no	Nothing is filed. The channel gets 400.	The error, so they can answer every question.
No answers (an older add-in or agent package)	The request is filed but held: a reviewer cannot approve it until the requester answers the screening.	It is held, with a link that opens the request with the questions showing.

Held requests

A request with no screening answers is held. This covers requests filed without them and requests from before the screening existed. Nothing stalls, though:

• The requester sees Answer screening on the request in Govern → Compliance program → AI requests. The link from Copilot, the add-in and the reminder email opens the questions directly. The requester can answer them while the request is submitted, in review or waiting for more information. In review, the screening is the only thing they can change.
• When a held request is filed, and whenever a reviewer tries to approve it, Shield360 emails the requester a link to the questions (at most once a day per request, when alert email is set up). It also raises an intake.screening_needed alert.
• When the requester answers, reviewers get the usual intake.submitted alert. A clear screening can then be approved. A flagged one cannot.

To request an asset the inventory has already seen, select Request approval on that asset in the AI inventory. The form opens already filled in with the asset. You can request any asset that is not approved, not covered by the list, under review or rejected. While a request for an asset is open, a second request for the same asset is refused.

The workflow

stateDiagram-v2
    [*] --> submitted: submit
    submitted --> in_review: start_review
    submitted --> more_info: request_info
    in_review --> more_info: request_info
    more_info --> submitted: respond
    submitted --> approved: approve
    in_review --> approved: approve
    submitted --> rejected: reject
    in_review --> rejected: reject
    more_info --> rejected: reject
    submitted --> withdrawn: withdraw
    in_review --> withdrawn: withdraw
    more_info --> withdrawn: withdraw

Status	Who acts next	Next steps
Submitted	A reviewer	Start review, request information, approve, reject. The requester can change the details or withdraw.
In review	A reviewer	Request information, approve, reject. The requester can withdraw.
More information needed	The requester	Respond, which sends the request back to Submitted. The requester can change the details or withdraw, and a reviewer can reject.
Approved	Nobody	Final.
Rejected	Nobody	Final.
Withdrawn	Nobody	Final.

What each decision records:

• Approve: a risk rating (low, medium or high), an owner, optional conditions and the day the approval lapses. The expiry must be after today and at most two years away. The form suggests the requested duration.
• Reject: a reason of at least 10 characters.
• Request information: the question. The requester’s answer is kept with it.

Approved, rejected and withdrawn are final. If the need comes back, submit a new request. A step that the request’s status does not allow is refused.

Each request shows a timeline of its steps: the step, the status before and after, the names of the fields it set, who took it (a user id) and when. The timeline never repeats the text; the text stays on the request.

The risk view

Reviewers, compliance officers and Auditors see a risk view on each request, built from what Shield360 has already observed about the asset:

• whether the inventory knows the asset, and whether it was seen in use in the inventory’s lookback;
• how many people and machines used it, and when it was first and last seen;
• its inventory status and what the approved-model list says about it;
• sensitive-data, prompt-injection and unapproved-model events in the last 30 days that were not allowed through;
• key-hygiene issues on the vendor’s keys;
• the inventory’s risk score.

It shows counts only, never the names of people or machines. From these, and from the kinds of data the request declares, Shield360 suggests a risk rating and lists why. For example, an asset that was rejected before is suggested as high, and credentials or regulated identifiers among the declared data raise the suggestion. The reviewer chooses the rating.

What a decision does

Each effect is applied separately and recorded on the request as a code, so the request shows what changed. If one effect fails, the others still run.

Approved. The inventory asset gets the decision through the inventory’s own record code: the owner, purpose and use case, the reviewer’s risk rating with the rationale “Rated when AI request <id> was approved.”, the status Approved by exception with the conditions and the expiry, and today as its review date. When the expiry passes, the approved-model list decides the asset’s status again, as for any inventory decision. A request for an MCP server, agent or application that the inventory has not seen yet records no inventory decision, because the asset has no key yet.

Approved model. A model is also added to the approved-model list that the AI proxy enforces, but only when that cannot widen or narrow anything else. The list is not changed when:

Situation	Why	Code
The list is off	Nothing is checked against it.	list_off
The list names providers only	Adding one model would restrict every other model of that provider, and adding the provider alone would approve all of its models. Edit the list yourself.	needs_list_edit
The list already covers the model	Nothing to add.	already_listed

Otherwise the model is added (model_added), together with its provider if the provider was not listed (provider_and_model_added).

High risk. When approving at high risk, the reviewer can also raise a risk in the risk register, linked to the asset.

Rejected. The inventory records the asset as Rejected. If it is seen in use afterwards, it counts as rejected AI still in use, raises the inventory’s alert and makes the Rejected AI is not in use check a gap.

Separation of duties

Nobody may review or decide their own request. The server refuses any review step taken by the person who submitted the request, whatever their role, and records the refusal in the audit log. The requester’s own steps (changing details, responding, withdrawing) belong to the requester alone.

Alerts

Kind	Raised when	Carries
intake.submitted	A request is submitted, or answered after a question, and waits for review	The asset type, the status, how many kinds of sensitive data were declared and the requested days
intake.decided	A request is approved or rejected	The asset type, the status, the risk rating and the expiry
intake.expiring	An approval lapses within 14 days. The daily control-history job raises it once per expiry date.	The asset type, the risk rating and the expiry
intake.screening_needed	A request is held until its requester answers the EU AI Act Art. 5 screening: when it is filed without the answers, and when a reviewer tries to approve it. At most once a day per request.	The asset type and the status

Alerts go to chat and email, so they never carry the name, purpose, justification or any other text someone typed. Each links to the request. Send them to a channel with an event rule on Alerts → Rules.

ISO/IEC 42001 evidence

The AI requests are decided by a reviewer check (intake.decisions) backs four ISO/IEC 42001 Annex A controls on Govern → Compliance program → Framework controls:

• A.6.2.5 Deployment planning
• A.9.2 Processes for responsible use of AI systems
• A.9.4 Intended use of the AI system
• A.10.3 Suppliers

Result	When
Not applicable	No request has been made in the environment, so an environment that does not use AI requests is not marked down.
Gap	A request has waited for a reviewer (submitted or in review) for more than 14 days since it was submitted. Asking a question and getting an answer does not restart the clock.
Met	Otherwise.

Every evidence package includes the requests for its period:

File	Contents
ai-requests.json	Every request submitted by the end of the period that was not already final before it began: its details, its status at the end of the period, the decision and its effects, and its steps up to the end. With counts of requests submitted, approved, rejected and withdrawn in the period, and of those open and overdue at its end.
ai-requests.csv	The same, one row per request. Text that starts with =, +, - or @ is defused for spreadsheets.

report.html and report.pdf have an AI requests and approvals section with the same counts and a table of the requests. The requester and reviewer are named by user id.

Auditor access

Auditors can read every request in their environment, with its timeline and risk view. They see user ids rather than names. They cannot submit, change, review or decide a request. In the public demo, every change is refused.

Data minimisation and privacy

• Text fields are short and capped: the name at 120 characters, the purpose at 500, the use case at 200, the users at 300, the justification, answer, conditions and rejection reason at 1,000, the question at 500 and the owner at 200.
• Steps hold no text: only the step, the statuses, the names of the fields set, a user id and a time.
• Each change is written to the audit log as intake.<step> (intake.submit, intake.approve, and so on), and each decision effect as intake.effect.<kind>, with ids, codes and counts. The text is left out, because it may name a person and the audit log outlives it.
• Requests and their steps are listed in the data inventory and are part of the organisation export as ai_intake_requests and ai_intake_events.
• A person export includes every request the person made (matched by their account’s email) and every request whose text names them. Erasure clears the text that names them and keeps the request, its decision and its steps.

Do not paste prompts, credentials or customer data into a request. Describe the data by choosing its kinds.

API

Method	Path	Parameters
GET	/api/governance/intake	Optional status (a status, or open), mine=1, type and q (name, vendor or asset key). The requests, newest first, with counts. Without intake.manage or compliance.read, only your own.
POST	/api/governance/intake	JSON body: assetType (tool, model, mcp_server, agent, vendor, application), name, purpose, justification, and optionally assetKey, vendor (required for a model), useCase, users, dataCategories and requestedDays. Needs intake.submit.
GET	/api/governance/intake/<id>	The request, its steps, the next steps you can take and, for reviewers, compliance officers and Auditors, the risk view.
PATCH	/api/governance/intake/<id>	The requester’s steps. JSON body: { "action": "update", ...details } while the request is submitted or waits for information, { "action": "respond", "answer" } or { "action": "withdraw" }.
POST	/api/governance/intake/<id>/review	The reviewer’s steps. Needs intake.manage. JSON body: { "action": "start_review" }, { "action": "request_info", "question" }, { "action": "approve", "riskRating", "owner", "expiresOn", "conditions"?, "raiseRisk"? } (expiresOn is yyyy-mm-dd) or { "action": "reject", "reason" }.

The environment comes from your session, and the requester is whoever is signed in; a database config id or requester in the body is ignored. Malformed JSON, an id that is not a request id, an unknown field value or text over its limit returns 400. Reviewing your own request, or a requester step on someone else’s request, returns 403. A request in another environment, or one you may not read, returns 404. A step the request’s status does not allow, a second open request for the same asset, or a request someone else changed meanwhile returns 409.

curl -X POST -H "Cookie: <session>" -H "Content-Type: application/json" \
  -d '{"action":"approve","riskRating":"medium","owner":"Data Science","expiresOn":"2027-04-30","conditions":"Team API keys only; no customer data."}' \
  "https://<your-shield360>/api/governance/intake/<id>/review"

Next steps

AI inventory

Where each decision is recorded, with its owner, rating, conditions and expiry.

Enforcement policy

The approved-model list an approved model is added to, and how the AI proxy enforces it.

Controls

The intake.decisions check and the ISO/IEC 42001 controls it backs.

Evidence package

A signed ZIP for an auditor, with ai-requests.json and ai-requests.csv.

Risk register

Where a high-risk approval can raise a risk.