Runtime Access Policies

A Runtime Access Policy defines the exact authority an AI agent may exercise through Gamut Gateway. It answers a narrow question:

May this agent perform this action, through this governed connection, on this resource, with this class of data, in this environment, for this purpose, at this time?

The answer is never inferred from an agent’s title, organisational position or general access to Gamut. Missing or ambiguous authority is denied.

Runtime Access Policies are managed from Agentic CISO → Access Matrix. The navigation label reflects the relationship between agents and resources. The records themselves are exact, versioned policies with a controlled lifecycle.

Where a Runtime Access Policy fits

A policy is one part of a defence-in-depth decision. It does not make an action permissible on its own.

Control	What it proves
Agent register	The agent has an accountable identity, owners and an active lifecycle state.
Gateway tool registration	The requested adapter is a governed capability known to Gateway.
Governed connection	The exact tenant and workspace connection is configured and ready.
Tool Permission	This agent is allowed to request the selected capability.
Runtime Access Policy	The requested action, resource, data, environment and purpose are within an active policy.
Approval gate	A qualifying sensitive action has the required human decision.
Runtime controls	Logging, monitoring, current policy validity and request-bound authority remain satisfied when the action executes.

Every applicable control must pass. A broad Tool Permission cannot compensate for a missing Runtime Access Policy, and an active policy cannot compensate for a suspended agent or unavailable connection.

Policy fields

Identity and effect

• Policy name: a human-readable description of the authority being governed.
• Agent: the registered agent to which the policy applies.
• Effect: Allow or Deny. Deny policies take precedence when an allow and deny boundary intersect.
• Risk rating: the assessed risk of the governed authority.

Capability and target

• Gateway adapter: selected from the agent’s active Tool Permissions.
• Governed target / connection: the exact ready connection for that adapter. Where Gamut provides a governed internal service, that service can appear as the target instead.
• Resource boundary: the specific object, collection or path the action may affect. A bounded trailing prefix can cover a defined collection. An unrestricted wildcard is treated as privileged authority and requires stronger justification and review.

The governed-target list is not free text. It is derived from the selected adapter and the connections that are available to the current tenant and workspace.

Action and information boundaries

• Exact actions: the operations the policy covers, such as read, retrieve, create, update, execute, send a message, export data or invoke a model.
• Allowed data classifications: the highest and specific information classes the action may handle.
• Environments: development, test, staging or production.
• Workflow boundary: an optional exact workflow to which the authority is restricted.
• Purpose boundary: an optional business-purpose restriction.

Choose only what the use case needs. If an agent requires unrelated actions or targets, create separate policies so each authority can be reviewed, suspended and replaced independently.

Assurance and time boundaries

• Human approval: whether execution also requires an approval gate.
• Gateway logging: mandatory for governed runtime authority.
• Continuous monitoring: whether ongoing runtime monitoring is required.
• Approver role: the accountable role expected where approval applies.
• Effective date: when the authority may begin.
• Expiry date: when the authority stops being valid.
• Review due date: when the business and security basis must be reconsidered.
• Business and security justification: why the authority is necessary, proportionate and time-bounded.

Dates have different purposes. Expiry controls runtime validity. Review due prompts governance attention. Reaching a review date does not silently extend an expired policy.

Policy lifecycle

Status	Meaning	Gateway treatment
Draft	The author is defining and validating the policy.	Not authoritative and not used to permit actions.
Pending approval	The submitted version is awaiting independent review.	Not active and not used to permit actions.
Active	The approved version is within its effective and expiry dates.	Eligible for exact runtime matching.
Rejected	The reviewer returned the proposal with a reason.	Not active. The author may revise and resubmit it.
Suspended	Previously active authority has been paused.	Immediately unavailable for new actions.
Revoked	Authority has been withdrawn.	Permanently unavailable.
Expired	The policy passed its expiry date.	Unavailable without a newly approved version.
Superseded	A controlled replacement became authoritative.	The replacement version is used; the prior version remains historical.

Submitted and authoritative versions are immutable. To change active authority, clone the policy, edit the new draft, validate it and send that new version through approval. This preserves a clear history of what was authorised at any point in time.

Authoring workflow

1. Establish the prerequisites

Before creating a policy:

1. Register the agent and assign its accountable owners.
2. Confirm the agent’s lifecycle and ATF level.
3. Register or enable the required Gateway adapter.
4. Configure and test the governed connection where one is required.
5. Grant the agent the matching Tool Permission.
6. Define an approval gate for actions that require human approval.

If the adapter or target does not appear in the builder, resolve the corresponding Tool Permission or connection first. Do not replace a missing governed target with a descriptive name.

2. Define the smallest useful boundary

Select one agent, one governed capability and a precise target. Add only the required actions, resource scope, information classifications and environments. Record the purpose and the reason the authority is proportionate.

3. Validate and review impact

Use Validate & impact before submission. Validation checks structural completeness and the relationship between the proposed policy and its governed context. Impact analysis helps identify:

• missing prerequisites;
• broad or privileged boundaries;
• overlapping active or pending policies;
• potentially contradictory allow and deny coverage;
• other active policies that could be affected.

Structural validity means the policy is complete enough to review. It does not mean the business risk is acceptable or that the policy is approved.

4. Save and submit

Save the proposal as a draft while it is being developed. When the content and impact are ready, submit it for independent review. Submission freezes that version and moves it to Pending approval.

5. Independently review

The reviewer should confirm:

• the agent, tool and target are correct;
• the action and resource boundaries match the stated need;
• the data classifications and environments are no broader than necessary;
• approval, logging and monitoring requirements match the risk;
• effective, expiry and review dates are appropriate;
• the justification explains necessity and proportionality;
• overlapping or conflicting policies have been resolved;
• the reviewer is independent of the creator and submitter.

The reviewer may approve and publish the policy or reject it with a reason.

6. Operate and reassess

An active policy remains subject to Gateway’s complete runtime decision chain. Reassess it when the agent, connection, tool, resource, purpose, data, environment, risk, approval requirement or organisational ownership changes.

Independent approval

Runtime authority can affect live systems, so approval uses a dedicated Runtime Policy Approver role. The role is assigned to the exact workspace containing the policies that person may review.

An approver can:

• inspect policy details and relevant supporting context;
• filter the approval inbox;
• approve a pending policy;
• reject a pending policy with a recorded reason.

An approver cannot use that role to draft, edit, delete, submit, suspend or revoke policies, administer users, operate Gateway or change agent governance records. Approval and rejection both require the approver’s own password and current MFA code through a short-lived step-up verification. The creator or submitter cannot approve the same policy.

See Users & roles for assignment and access details.

Execution-time validity

Approval is necessary, but it is not treated as permanently valid. When Gateway is ready to execute an allowed action, it checks that the authority still matches the request and that the governance state has not changed.

The execution is refused if, for example:

• the policy was suspended, revoked, expired or replaced;
• the policy content or version no longer matches the authorised decision;
• the agent, tool, connection, action, resource, data class, environment, workflow or purpose no longer matches;
• a required approval no longer applies to the exact request;
• the request-bound authority is missing, expired, replayed or inconsistent;
• required logging or monitoring cannot be satisfied.

This closes the gap between a decision being made and an action being executed. See Gamut Gateway for the complete runtime decision model.

View-only workspaces

When a workspace is locked in View only mode, existing policies remain available for inspection. Drafting and lifecycle changes are disabled. This supports audit and review without allowing the governance record to be altered.

Troubleshooting

The governed target list is empty

Confirm that the selected agent has an active Tool Permission for the adapter and that the required tenant and workspace connection is configured and ready.

A submitted policy is not visible to an approver

Confirm that:

1. the person has the dedicated Runtime Policy Approver account role;
2. that account has the Runtime Policy Approver workspace role for the exact workspace;
3. the policy is in that workspace;
4. the workspace assignment has not expired;
5. the policy status is Pending approval.

MFA is required to make the decision, not to list the assigned policy.

Approval asks for identity verification

The approver must enrol MFA, then complete the password and authenticator step-up. After successful verification, return to the policy and confirm the decision.

A previously allowed action is blocked

Review the current agent, connection, Tool Permission, policy, approval gate and runtime status. Gateway intentionally refuses to rely on an earlier decision when the current context no longer matches.

Worked example

A security triage agent needs to create a finding in Gamut from a verified SIEM alert.

The policy could specify:

• Agent: Security Alert Triage Agent
• Adapter: Gamut finding creation
• Target: the governed Gamut service
• Resource: the designated findings collection
• Action: create
• Data: internal
• Environment: production
• Purpose: convert verified security alerts into governed findings
• Logging and monitoring: required
• Expiry and review: time-bounded to the operational approval

The policy does not allow the agent to delete findings, modify users, change permissions or act on another workspace. Any additional authority requires its own explicit governance decision.

Next

• Agentic CISO: the wider governance system of record.
• Gamut Gateway: how policies are enforced at runtime.
• Tool and connection governance: how capabilities and targets become available.
• Govern an agentic workflow: the end-to-end operating sequence.