Requests
Requests is the administrative inbox for approvals across Rival Enterprise: the central queue where team members’ asks for new functions, agents, connectors, and workflows arrive for review. It is where the approval workflows defined in governance become a daily operational habit.
What lands here
Section titled “What lands here”Whenever a team member tries to execute an action or access an asset outside their approved boundary, the platform routes a structured request to this queue.
- Agent and function publishing — submissions from team members seeking to publish a newly built agent, function, or workflow to the shared organization Marketplace.
- Connector access grants — requests to reach enterprise systems that have not yet been granted to that user or team.
- Restricted capability escalations — asks to use an elevated foundation model, or to run a workflow that exceeds default financial or risk parameters.
Each request carries the context needed to decide: who asked, what data or systems it touches, its underlying logic, and the intended business use case.
Reviewing a request
Section titled “Reviewing a request”-
Inspect the context — review the asset’s security parameters, required data scopes, model routing, and underlying code or prompt logic.
-
Decide — approve, reject, or return the request with feedback.
-
Choose the scope of approval — approve the asset for the individual requester, or promote it to the whole department or organization.
-
Curate the catalog — approving for a broader audience enriches the internal Marketplace, so other team members adopt the approved asset instantly instead of filing duplicate requests.
Every decision, including rejections and timeouts, is recorded in the audit log with the reviewer’s identity and timestamp.
Why requests drive velocity
Section titled “Why requests drive velocity”A structured request queue turns security oversight from a bottleneck into an enabler.
- Controlled innovation — team members can reach for high-impact tools freely, knowing there is a clear path to request elevated access.
- No binary access — avoids the two failure modes of locking the system down completely, which stifles productivity, and opening it entirely, which exposes the business.
- Demand-driven growth — the library of approved AI assets grows from real operational need rather than administrative guesswork.
Request handling overview
Section titled “Request handling overview”| Request type | Triggering action | Review focus | Resolution impact |
|---|---|---|---|
| Catalog publishing | A team member submits a new function, agent, or workflow | Security guardrails, quality, PII compliance | Expands the internal Marketplace catalog |
| Connector access | A user requests a link to a restricted system | Data privacy, least-privilege necessity | Grants secure system access |
| Policy override | A workflow touches sensitive data or elevated cost | Financial limits, risk, human sign-off | Allows a high-consequence execution |
A worked example: scaled asset promotion
Section titled “A worked example: scaled asset promotion”Consider a high-value agent created by a support specialist.
- Initial submission — a support team member builds an agent that automates complex ticket categorization and requests to publish it to the department catalog.
- Administrative review — an Enterprise Admin opens the Requests queue, verifies the agent operates within the approved PII guardrails, and approves it.
- Departmental distribution — rather than approving it only for the author, the admin publishes it to the whole Support team’s Marketplace shelf, eliminating duplicate requests and lifting productivity across the department.