Agentic

Overview

Agentic is the workspace control plane for agent identity, tool and MCP discovery, authorization, approvals, and activity. The normal setup is five steps and uses friendly agent, tool, action, and server names throughout.

Identity proof
      ↓
Agent
      ↓
Authorization: resource + tool + optional action
      ├─ Allow → Tool or MCP executes
      ├─ Deny → Blocked
      └─ Require approval → Held for review
      ↓
Runs | Decisions | Trends

One control plane

Discovery tells you what exists; authorization decides what may run. Adding an agent, tool, or MCP server never grants access by itself.

One canonical MCP execution boundary

When Agentic authorization is enabled, all server-owned MCP execution surfaces converge before the tool is invoked:

Entry surface	Canonical behavior
JSON-RPC /mcp tools/call	Requires an exact Allow and returns a safe MCP error result for Deny, pending approval, or unavailable authorization.
POST /v1/mcp/tool/execute	Requires the same decision; responds with 403 Deny, 202 approval required, or 503 unavailable without executing.
Agent Mode	tools_to_auto_execute is only eligibility; each attempted call still requires Allow.
Code Mode	The outer code meta-call and every nested tool call are authorized separately.

That decision revalidates the current Virtual Key/agent binding, Registry action, exact-workspace OpenFGA relationships, optional context policy, and Command Authority state. Advisory/shadow configuration, catalogue visibility, an auto-execution list, or an OAuth grant cannot turn a Deny into execution.

MCP OAuth authenticates the gateway’s outbound connection or delegated upstream caller; it does not replace Agentic authorization. The legacy direct MCP result cache is also bypassed on canonical calls until a cache key can bind the complete agent subject, delegated identity, client generation, and decision. See MCP tool execution, MCP OAuth 2.1, and Relationship Authorization.

Navigation

Open Agentic in the workspace sidebar:

Page	Use it for
Agents	Use Needs attention for pending registrations, approvals, runtime keys, drift, and run incidents; Agent inventory, Denied agents, Discovery, and Shared assets for the workload lifecycle.
MCP Registry	Connect MCP servers and manage their tools and execution settings in the Connections and Settings tabs.
Identities	Manage users, groups, roles, permissions, service accounts, identity providers, and identity Provisioning.
Policy & Access	Use Guided access to grant and test least privilege, Action approvals for high-impact actions, Runtime policy for enforcement, and Enrolment for per-class rules.
Activity	Use Runs, Decisions, Trends, and Audit to investigate runtime traffic and administrative changes.

The current interface shown here uses synthetic demonstration data. Select Agent inventory to inspect a registered workload and Shared assets for reusable Tools & actions and Workflow maps. Agent-specific tools remain with their owning agent. Older Work Queue and Assets bookmarks redirect to this workspace; saved MCP connection bookmarks open MCP Registry.

MCP-only users retain MCP Registry when their Agentic access is otherwise limited. Connection inventory and workspace MCP settings remain together; the Settings tab loads only when selected and authorized. Open authorization-safe cache administration from Activity, and advanced relationship/model administration from Policy & Access.

The Security evidence view, opened from the Agents page header, separates configuration, enforcement mode, and observed decisions. Configured or No linked test is not a claim that a control has passed an end-to-end test. Investigate the linked policy or decision evidence before treating a category as verified.

Plans

Developer and Team workflows execute without Agentic Security. Team retains included policy configuration and historical activity. Business and above add governed execution, identity, integrity, approvals, and rollout controls. The same boundary is enforced on the API and in the console, and protected pages do not mount until the organization’s entitlements have loaded. Switching organizations clears the previous plan’s access immediately.

Capability	Team	Business
Agents → Needs attention and workspace Agentic Security switch	Upgrade	Yes
MCP Registry (within the plan’s MCP server quota)	Yes	Yes
Guided access console	Upgrade	Yes
Runtime policy: read configuration, author the external OPA/Cedar context policy	Yes	Yes
Activity: Runs, Decisions, Trends, and the Audit tab of relationship changes	Yes	Yes
Registrations, code reviews, drift review; Agents, Enrolment, Identities; AIBOM export	No	Yes
Temporary delegation (create, renew, revoke)	No	Yes
Action approvals (direct page, embedded panel, and approval APIs)	No	Yes
Runtime policy: enforcement mode and blueprint protection settings	No	Yes
Advanced relationships, model publication (canonical and compatibility routes)	No	Yes
Blueprint scans, Agentic observability, Agentic Cache	No	Yes

Developer and Team see Upgrade to Business in Agents → Needs attention and Guided access. On Business and above, workspace administrators can use the Agentic Security switch in Agents → Needs attention to turn the entire security workflow off or on. Existing workspaces default to on. When off, the SDK skips discovery, blueprint review, identity proof, decisions, approvals, and run-ledger calls. Each new invocation reads the current setting; turning it on restores the existing checks. Existing policies, registrations, and historical activity remain stored. Ordinary gateway authentication, workspace boundaries, and Virtual Key MCP restrictions continue to apply in both modes.

An already-enabled Block runtime drift policy remains fail-closed. Turn it off explicitly before disabling Agentic Security; a plan downgrade does not silently bypass that saved policy. The same restriction applies to Require a task mandate on every authorization: disable the requirement explicitly before turning off Agentic Security. A plan downgrade cannot silently bypass mandatory tasks.

A runtime policy save that mixes Team and Business fields is checked before anything is persisted. MCP server quotas are Developer 1, Team 25, Business 50, and unlimited on Enterprise; they count the whole organization across workspaces regardless of search or paging, new OAuth connections re-check capacity when they complete, and an unknown quota disables creation.

Set up Agentic in five steps

1. Review pending work and runtime policy

   Open Agentic → Agents → Needs attention and triage any registration, action approval, discovery drift, or blocked/failed run. Each row opens the exact review or evidence record. Then open Policy & Access → Runtime policy and confirm the mode is Enforcing. Use Advisory only for a temporary migration or access-change validation.

2. Authenticate people and agents

   Open Agentic → Identities → Identity providers. Connect the required Entra or Generic OIDC identity provider, enable and save it, and test the connection. Add or sync the people, groups, roles, and service accounts that may act through an agent from the other Identities tabs.

   Users and Service accounts show the most recently created entries first. After manually adding one, search and source filters clear and the table returns to page one. The page size adapts to the viewport with a minimum of two rows when available; on short screens, scroll to reach all rows and controls.

   Use Authorize provisioning in the separate Provisioning tab to attach customer-approved management access to the selected verifier. Its issuer, audience, and Entra tenant/blueprint are inherited and shown read-only. The connectors cover Entra Agent ID, Keycloak, Auth0, and Okta. Keep an identity for the logical agent and environment across runs; do not provision one per invocation. Secrets are delivered to the customer’s Vault, or the workload uses supported public-key authentication, direct Entra federation, or Entra gateway runtime authentication. In gateway mode, separate blueprint credentials stay on the gateway and the SDK enrolls an approved runtime key. Follow the complete Microsoft + local gateway setup for math-agent, pasted encrypted management credentials and opt-in automatic Gateway.Invoke assignment. Linked identities stay read-only. Provisioning does not replace proof or registration review.

   A new Entra verifier defaults to Shared agents · explicit identity list. The empty list admits nobody and can be validated before creating the first child. Provisioning adds exact child IDs. Existing single-child and shared admission policies stay unchanged until an explicit permitted edit.

   Created & linked counts provisioning records separately from existing identity declarations. If verifier settings change before provisioning starts, use the connection’s explicit Use current verification settings action. See provisioning records and recovery for the distinction and restrictions on used connections.

   For a newly discovered workload, configure its owner and identity in the single Review workspace under Agents → Needs attention → Registrations. Selecting an identity provider or declaring an expected identity does not prove that the workload holds its credential. The gateway must observe matching verified proof. Configure direct workload credentials or approve the intended gateway runtime key, then rerun discovery if proof is missing. Explicit VK-trusted approval is only for deployments that deliberately accept unattested Virtual-Key trust. Use Identity & credentials for later changes to an active agent. See Agent workload identity for provider types, identity-class matching, accepted token lifetimes, replay protection, and proof-of-possession.

   Once several agents share an issuer, author an enrolment policy under Agentic → Policy & Access → Enrolment so matching workloads arrive already described and the review queue holds exceptions rather than the whole population.

   Deployment builds may optionally prefill a new, disabled Entra provider draft with these public identifiers:

   NEXT_PUBLIC_AGENTIC_ENTRA_DISPLAY_NAME
   NEXT_PUBLIC_AGENTIC_ENTRA_TENANT_ID
   NEXT_PUBLIC_AGENTIC_ENTRA_AUTHORITY
   NEXT_PUBLIC_AGENTIC_ENTRA_GATEWAY_AUDIENCE
   NEXT_PUBLIC_AGENTIC_ENTRA_BLUEPRINT_CLIENT_ID
   NEXT_PUBLIC_AGENTIC_ENTRA_AGENT_IDENTITY_CLIENT_ID
   NEXT_PUBLIC_AGENTIC_ENTRA_JWKS_URI
   NEXT_PUBLIC_AGENTIC_ENTRA_MI_PRINCIPAL_ID
   NEXT_PUBLIC_AGENTIC_ENTRA_SCOPES

   These values are compiled into downloadable browser JavaScript. They never override a provider saved in the active workspace and must never contain a client secret, token, certificate, private key, password, connection string, or secret reference. Shared multi-tenant SaaS builds should leave all nine unset and configure providers independently in each workspace.

3. Discover agents, tools, actions, and MCP

   For each MCP server, open Agentic → MCP Registry, choose its transport and authentication method, and create the live connection. Use Settings on that page for workspace MCP configuration. Then compile or run the discovery-enabled agent workflow once.

   Confirm the live connection and friendly tool names in MCP Registry → Connections. In Agents → Agent inventory, open the discovered agent and inspect its own tools and actions. Use Shared assets for reusable tools and workflow maps. Confirm names, status, and risk before granting access.

   Every SDK-discovered action stays conservatively classified write/high until an operator classifies it; an agent never classifies its own tools. For a discovered tool listed under Shared assets → Tools & actions, Review & classify pre-fills class and risk from its declared values as suggestions. The registration review shows each action’s current class and risk with Class, Risk, and Require approval controls for the reviewer to set; the server keeps enforcing write/high until the review is saved. In Tools & access, select each required Actions to allow entry and the exact resource permissions under Roles & resources and Additional access. Tool classification is not a resource grant. Review Confirm these changes, then choose Confirm approval and access. This approves the registration, its exact completed blueprint, and the selected access plan through one confirmation. A separate first-registration blueprint approval is not required.

   For brokered MCP tools, Agents → Shared assets → Tools & actions → Import from MCP lists a connected server’s live tools and, in one action, registers each under its canonical versioned key with the chosen class and risk, mints the derived <canonical>:read permission, attaches it to the selected agent principal, and writes the allowed_caller grants, the same records the manual register-grant-permit steps produce. An unregistered brokered tool stays write/high and routes to the approval gate instead of answering Allow.

   The developer side of this step is one run. With SDK 3.2.0 or newer, run the agent with four settings: DEEPINTSHIELD_BASE_URL, DEEPINTSHIELD_VIRTUAL_KEY, DEEPINTSHIELD_AGENT_NAME and DEEPINTSHIELD_REGISTERED_BY (constructor argument registered_by), which names the registering developer. Run 1 captures the source, enrols the runtime key when the workspace offers a provisional Entra provider, and prints one line:

   Registration pending. Reference <registration id> · runtime key SHA256:<thumbprint>. Contact your administrator. You will be notified at <email>.

   There is no review link; the developer cannot approve. DEEPINTSHIELD_REGISTERED_BY is the explicit way to name the registering developer. The gateway maps it to a person in the workspace directory and notifies it; it is not verified and grants nothing. One registration keeps its first address: a different address on a later run is refused with registration_requester_mismatch. Without it, an e-mail-shaped requester is only an advisory hint: the gateway uses it only for a person the organization placed in the workspace and ignores it otherwise, without refusing the run. The closing sentence of the line, You will be notified at <email>., appears only when the gateway confirmed the address. The administrators receive a review-needed e-mail and the developer a pending receipt; see Registration notifications.

   The administrator then finishes the registration in one sitting: confirm the owner proposed from the registering e-mail, or choose another; create or link the identity in Identity & owner (or select Approve as VK-trusted (development only) when the workspace setting allows it); Authorize runtime key against the thumbprint the developer received; review Code & changes and Tools & access; then Confirm approval and access or, while workload proof is still outstanding, Approve now · activates on next run so the developer’s next run of the unchanged script executes. See Deferred activation.

   If the deployment deliberately accepts Virtual-Key trust without workload attestation, explicitly select Approve as VK-trusted (development only). A declared identity is optional: use the Expected identity card when you know the provider identity the friendly name is expected to prove. The option is offered only while Policy & Access → Runtime policy → Registration review → Allow VK-trusted approvals (development only) is on, and it cannot be deferred. Keep that setting off in production workspaces. This is a separate trust choice, not a remedy for missing credentials in a deployment that requires verified proof. The agent is recorded as unattested with a declared exit; when it later presents a verified token for that identity, the review shows a Token verified · confirm identity proposal and Confirm attestation binds the provider while the agent keeps its subject and every grant. See Expected identities.

4. Grant and prove least privilege

   Initial access belongs in registration review. For additional grants or a runtime check, open Agentic → Policy & Access → Guided access. Select:

   • the agent and, when applicable, the person or service account it acts for;
   • the target resource and required permission;
   • the tool; and
   • the exact named action, when the tool exposes one.

   Add a time-limited delegated scope only when the agent acts on behalf of another identity. Click Grant access, then Check access and review every result before running production traffic.

   High-impact actions are held in Agents → Needs attention and Policy & Access → Action approvals. Review the agent, actor, tool, action, and target, then approve or deny. An approval cannot override a hard denial. Approvals are subject to separation of duties; see Who may approve below.

5. Run and observe

   Route the agent and MCP traffic through the DeepIntShield gateway, then open Agentic → Activity:

   • Runs shows one workflow and its agents, tools, actions, and outcome.
   • Decisions explains each Allow, Deny, or Require-approval result.
   • Trends summarizes volumes, outcomes, top agents and tools, and latency.
   • Audit records the latest 200 relationship access changes separately from runtime decisions. Model history is under Advanced → Policy model → Changes.

   Use Activity → Trends for activity and outcome graphs and select Secure caches from Activity for authorized cache savings. Langfuse/OpenTelemetry export is managed by the backend deployment and is not a workspace form. Export failure never changes or removes the local authorization record.

For the exact simple-math-agent LangGraph example and its two invoke actions, follow First run: simple math agent. After confirmation, Approved. Selected access is ready. reports the saved plan; Server checks passed reports the available runtime checks. Neither grants an unconditional Allow for future actions. If the plan is incomplete, use Resume saved approval and resolve the checks listed under Runtime setup needed before retrying.

Finish a registration review

Open the registration from Agents → Needs attention → Registrations: select Review on its row, or Review next agent for the next pending one. The review workspace keeps the queue filters when you return. The checklist has six sections: Identity & owner, Code & changes, Tools & access, Runtime access, Validate changes, and Review & decide.

Resolve the owner, identity, code, and exact access prerequisites below, then inspect runtime readiness, validate the changes, and make the final decision. Completed checks remain available for inspection.

Check	What makes it ready	If it is blocked
Owner	Required agent details and an active human accountable owner	Add or select the owner; keep the workload’s existing workspace key.
Identity	A validated eligible provider and matching workload proof, or an explicitly permitted VK-trusted review	Create or link the identity in Identity & owner, authorize the runtime key the developer’s first run enrolled, then record the decision with Approve now, activates on the agent’s next run; the next run supplies the proof. Without deferred activation, use Run setup under Runtime access, rerun the workload, and select Check proof.
Code	Complete executable source coverage and a completed scan for the current revision	Run the saved source file with a compatible SDK; correct scanner configuration or source capture, then refresh the review.
Access	Reviewed exact tool actions, classifications, and selected resource permissions	Select only required actions and permissions; optional roles, groups, and reusable access choices do not need to be created for a simple agent.
Reviewer	A person other than the accountable owner, and other than an administrator who registered the agent with their own sign-in e-mail, for every deferred decision; also for an immediate approval when Require a separate reviewer for immediate approvals is on	Ask another administrator (approver_conflict_of_interest). In a one-person workspace, approve immediately after the agent’s next run (three runs).

No tools found. No tool access needed. describes the current discovery record. It does not prove that discovery captured every callable. In the simple math example, complete discovery should expose add_two/invoke and multiply_by_three/invoke. If that workload shows zero artifacts and zero tools, resolve source capture before approving it. Local arithmetic needs no additional resource permissions, but its discovered executable actions still need review.

When the required checks are ready, open Review & decide and click Preview approval, inspect Confirm these changes, then Confirm approval and access. A denial requires a note. The preview applies to the current identity, blueprint, and access selection; refresh and review again if any of those change.

If the result is Plan saved · access incomplete, use Resume saved approval to finish the remaining operations. If it says Review access again, inspect the conflict and Review remaining access in Guided access. Archive conflicted plan, when offered for an already registered agent, removes the recovery item after a reason and confirmation; it does not undo existing grants. A completed plan can be saved for reuse, but each new workload still requires its own identity, code, and access review.

Deferred activation

When the only outstanding check is the declared identity’s workload proof, the reviewer can approve without waiting for another run. In Review & decide, select Approve now, activates on the agent’s next run and confirm with Approve now · activates on next run. The response is Decision recorded: the registration stays pending, and the decision is pinned to the current source digest, the completed scan, the expected-identity declaration revision and the single authorized runtime-key binding. The developer is e-mailed.

On the agent’s next attested run of the unchanged script, the gateway verifies the runtime key and identity, applies the decision while it handles that run’s discovery request, and answers with the registration approved; the blueprint scan reports complete and the agent executes. Nothing is added to the authorization path. Anything that changed in between - the code, the scan, the identity declaration, the runtime key, the provider, the owner, the reporting key or the reviewer’s account - marks the decision Stale decision · <reason> and the run stays pending. The administrators and the developer are e-mailed that the decision is stale, and the registration needs a new review. A decision not used within AGENTIC_DEFERRED_DECISION_TTL_HOURS (168 hours by default) shows Expired. Withdraw decision voids it; the card then shows Withdrawn.

Deferred activation requires a reviewer who is not the agent’s accountable owner and did not register the agent with their own sign-in e-mail; the review shows You registered this agent or are its accountable owner. A recorded approval needs a different administrator. You can still approve after the agent’s next run. when that applies. It is available only when a declared identity exists, the scan is complete, no access plan is part of the approval, and either gateway exchange has exactly one approved, enabled runtime key for the agent or direct mode is allowed. Approve as VK-trusted (development only) cannot be deferred, and control-plane tokens cannot record a deferred decision (decision_reviewer_unidentified).

A recorded decision carries the registration, the reviewed code and every tool action the reviewer selected in Tools & access. The Decision recorded card lists the actions that activation will grant, so the agent’s next run executes the whole agent: in the simple math example both add_two/invoke and multiply_by_three/invoke are granted and the run prints {'number': 21}. Resource permissions, roles and delegations are not part of a recorded decision; when an agent needs them, add them after activation in Guided access.

Workspaces whose scan mode is static_and_model apply the decision on the run after the model scan completes. Gateways without deferred activation keep the earlier sequence: authorize the key, run for proof, approve, run again.

The registration route by identity type

Every identity type follows the same route: run 1, one review sitting, then the next run. What the sitting contains and what the developer needs before run 2 depend on how the agent proves who it is.

Identity type	What the administrator does in the sitting	What the developer needs before run 2	Runs	Server runs
Plain virtual key (VK-trusted)	Confirms the owner, reviews code and tools, and selects Approve as VK-trusted (development only), with or without a declared identity. The option is offered only while Allow VK-trusted approvals (development only) is on (Policy & Access → Runtime policy → Registration review). Keep that setting off in production workspaces. A VK-trusted approval is never recorded for later and never automatic.	Nothing new: the four settings and pip install deepintshield.	Two	No. Where server runs reach every workspace (*, the default), the program runs on the developer’s machine after its server run ends, and in this release that first local run asks for one more code review. In a workspace listed for server runs the agent cannot run (managed_gateway_runtime_required).
Microsoft Entra with gateway exchange	Confirms the owner, creates or links the identity, authorizes the runtime key by its thumbprint, reviews code and tools, and selects Approve now, activates on the agent’s next run.	The four settings and pip install 'deepintshield[runtime]' from run 1, on the same machine.	Two. Three when no runtime key arrived on run 1.	Yes. It is the only identity type that can finish a server run.
Microsoft Entra direct	Confirms the owner, declares or creates the identity, reviews code and tools, and records the decision. There is no runtime key to authorize.	An Azure host whose identity the agent blueprint trusts, the four settings and pip install 'deepintshield[azure]'. It never works from a laptop.	Two, on an Azure host	No, as for a plain virtual key.
Generic OIDC: Okta, Auth0, Keycloak and any issuer	Confirms the owner, declares the agent’s token subject, reviews code and tools, and records the decision.	The agent’s own client credential on the machine: OIDC_CLIENT_ID plus OIDC_CLIENT_SECRET, or OIDC_CLIENT_AUTH_METHOD=private_key_jwt with OIDC_PRIVATE_KEY_FILE.	Two, only when that credential is on the machine before run 2	No, as for a plain virtual key.
ZeroID (experimental)	The provider is configured through the API beforehand. In the sitting, the same steps as Generic OIDC.	ZEROID_SUBJECT_TOKEN and ZEROID_EXCHANGE_ENDPOINT.	Two, when both are set before run 2	No, as for a plain virtual key.
SPIFFE	Not available for registration. A SPIFFE provider cannot be created.	Not applicable	Not applicable	Not applicable

For Generic OIDC, the issuer and its signing keys must be reachable at a public https address on port 443. A Keycloak on a private network therefore cannot be verified. The gateway accepts tokens that live one hour or less; set the token lifetime at the issuer. The subject to declare depends on the issuer: for Okta it is the client id, for Auth0 <client id>@clients, and for Keycloak the service-account user id.

An administrator who registered an agent with their own sign-in e-mail cannot record its decision. While Require a separate reviewer for immediate approvals is on, they cannot approve it at all. In a one-person workspace, approve immediately after the agent’s next run (three runs), or register the agent with a different e-mail.

Optional server-managed onboarding

When an operator enables server-managed execution on the gateway, for every workspace at once or for selected workspaces, SDK 3.2.0 can submit a supported standalone LangGraph program once for one isolated server run. Finish identity, server runtime key, code, and access review in the same workspace; the saved job waits without keeping the client process open. Runtime access → Server run shows its setup progress and outcome. With a gateway and SDK that support submission IDs, running the unchanged script again starts a new server run under the existing approved registration; an active or uncertain run must be resolved first. Clients without submission IDs get the same saved job back. Local execution remains the default. Only an identity that uses gateway exchange can finish a server run; see the registration route by identity type.

See Server-managed agent execution for supported programs, worker prerequisites, bounded action-approval waits, compatibility errors, cancellation, and uncertain-outcome recovery.

Temporary delegation

For an agent acting for a person, open Policy & Access → Guided access → Temporary delegation. Select Agent, For user, Resource type, Resource name, and Expires in, then click Create delegation. The agent, user, and exact resource must match the runtime request. Run Check access afterward; delegation does not supply missing resource or tool grants.

If the integration requires a delegated credential, use Mint actor token on the active delegation. Select the configured identity provider, supply the user access token and any required agent assertion, then copy the returned short-lived actor token before closing the dialog. Creating the delegation alone does not mint that credential, and setting a requester email alone does not prove the user’s authority. See workload identity for token verification.

Use Revoke delegation to end future delegated access. Renew expiring is a bulk operation: it extends eligible delegations expiring within 24 hours, including those that lapsed within the last seven days, to the workspace TTL ceiling. Review the affected delegation population before using it.

Task controls

Open Policy & Access → Runtime policy → Task scope and authorization ancestry to bound a task without changing the agent’s standing grants. Executing under a mandate and enabling the workspace-wide requirement need available, enabled Agentic Security. Task authoring can precede runtime enablement. The deployment must configure DEEPINTSHIELD_TASK_SIGNING_KEY as a base64-encoded secret containing 32–128 bytes; if signing is unavailable, issuance and enabling the requirement are disabled. Configure the secret on the gateway, not in a workload or browser.

1. Click New task and enter Purpose, Expires at · local time, and Maximum authorizations. Expiry must be within 24 hours; the budget is between 1 and 10,000 authorizations.
2. Fill each Action scope with the exact agent subject, tool subject, action, permission, and resource object used by the governed request. Wildcards are not accepted. Add only the scopes needed for this task.
3. When required, expand Labels, parents and memory to set produced or rejected classifications, required parent receipts, memory read slots, and a write slot. Optional action sequence defines an initial state and the permitted transitions between scoped actions.
4. Click Review task, review the exact bounds, acknowledge them, then click Issue task token. Copy token while it is visible; the token is shown once and cleared when the panel closes. Deliver it through the workload’s credential mechanism and use the SDK task scope.
5. After workloads successfully supply mandates, optionally enable Require a task mandate on every authorization, review the effect, and click Confirm policy change. Existing callers without mandates will be denied.

Each authorized action consumes a budget unit even if execution later fails. A mandate narrows existing access; it does not grant permissions or replace verified workload identity. Defining a sequence permits only its listed transitions.

Task details show authorization ancestry and versioned, workload-reported memory digests. The SDK can carry task metadata around an existing native framework invocation; ordinary invocations remain unchanged when tasks are not required. Memory digests must be calculated from the bytes actually being used. They do not establish content safety or complete dataflow provenance. Revocation stops future authorizations; it cannot undo a tool that already started. Select a task to Refresh evidence, inspect its Recorded exact scope, authorization receipts, current memory digests, and commitment history. To end it, choose Review revocation, acknowledge the effect, and Confirm revocation. Receipts record authorization, not successful tool completion.

Registration and agent access views also support inline permission creation and role/group administration. Creating a catalog item does not automatically grant it. Assignments require an approved active agent and explicit review.

Blueprint code review

Supported framework execution binds registration to implementation evidence, not just an agent or tool name. Native discovery sends a bounded, credential-redacted source bundle and a mandatory coverage ledger for every declared local executable. Missing, partial, truncated, or omitted coverage fails closed as blueprint_coverage_incomplete; a scanned prefix is never treated as safe.

A remote MCP tool is exempt from local source capture only when the server matches its selector to a configured MCP connection in the authenticated workspace. Adding an arbitrary remote-server label to a discovery report does not create an exemption.

Version	Role
static-v2	Required deterministic scan. It emits fixed, source-free findings.
model-v2	Optional additive model prompt/schema. It cannot erase static findings, declare code safe, or approve a blueprint.

Configure and review code protection

1. Open Policy & Access → Runtime policy → Blueprint protection. The static scan is required; no model credential is needed for static-only review or for the arithmetic example.
2. To add model analysis, enable Model review, select an eligible protected Virtual Key and one of its permitted models, then Save. This is the scanner’s model route, independent of the agent’s inference configuration.
3. Set Block runtime drift according to the change policy below and save.
4. Run the saved workload to submit source evidence, then open the exact registration or code review in Agents → Needs attention. Review artifact coverage, static/model findings, and the scan state. Pending or failed model evidence keeps approval locked; correct its key/model route and rerun discovery.
5. For first registration, finish Confirm approval and access in the registration form. For an existing agent’s pending code revision, use the code review’s Approve digest or Deny with a required denial note. Rerun the workload after approval; runtime access still applies.

Configure optional model analysis under Policy & Access → Runtime policy → Blueprint protection. The protected Virtual Key picker searches the active workspace with bounded, server-paged requests, can reach keys beyond the first 200 rows, and reloads the selected key’s actual provider/model configuration. It retains an exact configured key outside the current page, accepts eligible organization-wide keys, rejects sibling-workspace keys, and does not display or submit the key secret. Explicit model restrictions are intersected with the key’s provider restrictions; unrestricted routes use a filtered model catalog. A key’s name does not determine its provider.

Changing keys immediately clears an incompatible model. A sole eligible model is selected automatically; multiple choices require a selection unless the existing one remains valid. Provider-qualified model values disambiguate multiple routes. Loading failures and superseded responses cannot restore models from a previous key or workspace, and block saving unverified model review settings. A runtime-drift-only save leaves model review settings unchanged. The server validates the final key/model route on save.

A code digest, static-v2/model-v2 version, policy generation, or protected key/model routing change requires fresh attestation. New or changed code waits for one bounded synchronous scan acknowledgement. Unchanged approved code avoids repeated scanner/model calls, but normal authorization and network latency still apply and must be measured for the deployment.

A re-scan is compared against the agent’s approved baseline. The workspace setting Block runtime drift controls whether a clean delta can proceed:

Setting	Newly observed code digest
Off, the default (blueprint_runtime_enforce: false)	Mandatory scanning remains active. A change with no new or escalated findings can be admitted against a valid approved baseline; new or escalated findings quarantine the agent for review.
On (blueprint_runtime_enforce: true)	Every different observed digest requires fresh review and quarantine, even when scans find no new risk.

Enable Block runtime drift in Blueprint protection, then select Save. Agentic Security must be enabled. A rollback to an older approved digest is a newly observed revision and also requires review when strict mode is on. Turning the setting off does not approve a pending revision or release an existing quarantine. Review findings and the exact revision in Agents → Needs attention. Resolved findings remain visible in the delta; approval evidence and digests are retained without retaining source text.

No SDK changes are required. Existing callable-change reports and gateway-observed tool definitions are checked before subsequent protected actions; unchanged approved evidence adds no scanner or model call per action. This does not monitor the local filesystem, host memory, or unreported remote implementation changes, sandbox arbitrary code, or cancel an action already running. Changes outside reported and gateway-observed paths are not monitored.

Static and model findings are bounded risk signals, not perfect detection or proof of safe code. Keep signed builds, repository review, dependency controls, sandboxing, egress policy, and gateway authorization in place.

The SDK renders stable machine codes rather than remediation prose. Common codes include agent_registration_pending, blueprint_coverage_incomplete, blueprint_scan_unavailable, require_approval, and guardrail_denied. Agents → Needs attention, blueprint/registration review, action approvals, and Activity → Decisions own the human explanation and next action.

See Agents and Agentic governance for the Python enforcement surface and SDK error codes for every stable code, trusted description, retry hint, operator action, and dashboard path.

Who may approve

An approval gate that the requester can close themselves is a confirmation dialog, not a control. Two rules apply to every high-impact action approval, and a third applies the same principle to registration review:

• Designated approvers. When an action carries a list of required approvers, only someone on that list may decide it.
• Separation of duties. Being designated is necessary but not sufficient. The person who requested the action cannot approve it, and the agent’s accountable owner cannot approve that agent’s actions; the owner is answerable for what the agent does, so asking them to sign off is asking them to review themselves.
• Registration review. The reviewer cannot be the agent’s accountable owner for a deferred decision, nor an administrator who registered the agent with their own sign-in e-mail. Policy & Access → Runtime policy → Registration review → Require a separate reviewer for immediate approvals (default off) extends the rule to immediate approvals, so single-administrator workspaces keep working by default. Allow VK-trusted approvals (development only) (default on) controls whether the unattested option is offered at all; keep it off in production workspaces. Denials are not restricted. In the console, the Registration review card is on the Runtime policy tab of Policy & Access.

If the agent’s accountable owner cannot be resolved, the approval fails rather than skipping the check. Approval expiry defaults to five minutes and can be configured by the deployment, up to 24 hours. Approvals commit their state transition and their evidence record in one operation.

Advisory (shadow) mode does not bypass this. A verdict of Require-approval stays Require-approval in every enforcement mode; advisory affects Deny, not a pending human decision.

Captured 10 October 2026 with synthetic demonstration data.

Agent-owned tools and retirement

SDK-discovered local tools belong to the authenticated agent. Two agents with the same friendly function name still have separate tool identities and access grants. Inspect these under Agent inventory → select agent → Tools & actions. Shared assets remains the place for shared inventory; a caller-supplied MCP server/name cannot turn a local function into a shared gateway tool.

agent_tool_scope_mismatch means the requested tool belongs to a different agent or its identity does not match. agent_tool_identity_review_required means discovery and review have not established the current owned tool identity. Reopen that agent’s review and approve the exact current actions; old workspace-wide local-tool grants do not migrate into new authority implicitly.

For an obsolete workload, an authorized manager can use Retire obsolete agent from the inventory or denied-agent review. Inspect the current preview, enter a reason, and explicitly confirm its subject. Retirement permanently prevents future execution and cannot be undone. It releases that agent’s blueprint holds while preserving denied reviews, registration history, and recorded activity. Other agents’ holds remain visible and retain their effect.

Review inventory and tool definition changes

Use Agents → Shared assets → Workflow maps to inspect the SDK-reported topology and Agents → Discovery to inspect created, seen, and drift events. Inventory shows what was reported; it is not a new access grant or evidence of successful execution.

For a changed MCP tool contract, open the drift item in Agents → Needs attention or the definition review in Agents → Shared assets → Tools & actions. Definition changed shows the approved and currently advertised contract digests and when drift was first seen. Inspect the actual description or argument-schema change at its source; the dialog does not show a schema diff. Calls stay denied while that change is pending. Approve new definition re-pins existing grants and approvals to the new contract; use it only after reviewing the upstream change. Keep denying leaves the block in place. Disconnect the server if the changed definition cannot be trusted.

This contract review is separate from a local executable’s blueprint digest review. Deleting a tool or network inventory row is also separate from revoking its grants. Review and remove unneeded access explicitly through Policy & Access, and inspect the resulting changes in Activity → Audit.

Evidence integrity and retention

Every decision is appended to a workspace-scoped, append-only, hash-chained ledger before the call proceeds. Two operator-facing controls sit around it.

Verify a decision chain

Activity → Decisions reports integrity as a status rather than exposing hashes. To re-verify independently, call the verification route with an operator session:

curl -sS "https://gateway.example/api/agentic-new/decisions/verify"   -H "Authorization: Bearer $SESSION_TOKEN"

It recomputes the chain and reports whether it is intact. A broken chain is a successful verification with bad news in it, not a failed request.

Key the chain in production

Variable	Effect
DEEPINTSHIELD_ENV	Declares the deployment kind. Only production / prod is load-bearing.
DEEPINTSHIELD_AUDIT_HMAC_KEY	Keys the decision chains. Minimum 16 characters.
DEEPINTSHIELD_AIBOM_SIGNING_SEED	Signing seed for AIBOM attestations. Minimum 16 characters.
DEEPINTSHIELD_SIEM_SIGNING_KEY	Shared secret used to authenticate exported events to a receiving SIEM.
DEEPINTSHIELD_AGENTIC_RETENTION_DAYS	How long agentic evidence is kept. Defaults to 730 days.

Unkeyed chains are only evidence against someone who cannot run SQL

Without DEEPINTSHIELD_AUDIT_HMAC_KEY the chains are bare SHA-256 over data the database itself holds, so anyone with write access to it can alter a decision and recompute a hash that still verifies. A deployment declaring DEEPINTSHIELD_ENV=production refuses to start unkeyed; anywhere else this is a startup warning so local and CI runs do not need a secret to boot.

The key must then stay stable; rows written under one key stop verifying under another. Enabling it needs no migration: the algorithm is recorded with each row, so existing rows keep verifying under the scheme that produced them.

Without DEEPINTSHIELD_AIBOM_SIGNING_SEED, AIBOM documents are returned explicitly marked unsigned with a reason, rather than carrying a signature from a built-in key. Treat an unsigned document as not attested, not as a signature that failed to verify.

Exported SIEM events are HMAC-signed over the exact bytes sent, with a timestamp inside the digest so a captured event cannot be replayed indefinitely. With no key configured the export is unsigned and otherwise unchanged; the local hash-chained ledger remains the source of record either way.

Retention sweeps decisions, approvals, blueprint scans, and registration archives past the configured period in bounded batches.

Captured 10 October 2026 with synthetic demonstration data.

Optional external context policy

Normal relationship authorization does not require this integration. Use it only for OPA or Cedar attribute rules such as risk, time, location, or data sensitivity:

• OPA (Open Policy Agent) applies Rego policies to flexible JSON input.
• Cedar applies permit/forbid policies to a structured principal, action, resource, and context request.

DeepIntShield runs identity, delegation, permission, tool, and action checks first. If they pass, it sends the relevant runtime attributes to the configured engine. The request is allowed only when both the relationship checks and the external context decision allow it.

1. Deploy the OPA or Cedar decision endpoint.
2. Allowlist a non-local host with AGENTICNEW_CONTEXT_SIDECAR_ALLOW_HOSTS.
3. Expand Agentic → Policy & Access → Runtime policy → External context policy.
4. Select the engine, enter the complete decision URL, and select Save & enable.

The URL field reports missing, invalid, and server-rejected values. Evaluation is fail-closed, so leave the integration off when no external policy service is deployed.

Expected outcomes

Outcome	Meaning	Next action
Allow	Identity, resource permission, tool, applicable action, and optional delegation checks passed.	The action may run.
Deny	At least one required check failed or the resource is inactive or untrusted.	Open Activity → Decisions and correct the missing access or configuration.
Require approval	Access is otherwise valid, but the action needs human review.	Open Agents → Needs attention or Policy & Access → Action approvals.

Friendly names and signed evidence

The everyday UI shows display names for agents, identities, tools, actions, servers, runs, and decisions. Activity pages summarize evidence integrity as a status instead of exposing internal identifiers or cryptographic values.

Signed inventory exports from Agents → Shared assets may include canonical identifiers and cryptographic proof for audit verification. Those values are audit evidence, not fields users need to copy into normal Agentic forms. Click Export AIBOM to download the JSON inventory of governed tool contracts. Check its attestation state; without the deployment signing seed, the document is explicitly unsigned.

Advanced configuration

From Policy & Access, open Advanced → Relationships or Advanced → Policy model when you need to:

• edit and publish the OpenFGA authorization model;
• manage raw relationships or model assertions;
• inspect model and relationship changes; or
• run low-level authorization diagnostics.

Treat model and relationship changes like code: test positive and negative assertions, review the change, publish it, and verify access again.

In the model editor, expand Preview access changes, select the relevant saved assertions (up to 100), and click Compare access. Inspect checks that allow more, allow less, or failed. This saves an inactive model version for the comparison; it does not publish the model, grant access, or execute tools. If the active model changes during comparison, rerun it before deciding whether to publish. See Relationship Authorization.

Operator tunables

These gateway environment variables adjust Agentic timing and registration e-mail. All require a server restart; an empty or invalid value keeps the secure default.

Variable	Default	Hard cap	Controls
DEEPINTSHIELD_AGENTICNEW_APPROVAL_TTL_SECONDS	300 (5 min)	24 h	How long a pending action approval stays actionable before it expires. Raise it when reviewer conversations run longer than the default window.
DEEPINTSHIELD_AGENTICNEW_OBO_MAX_TTL_SECONDS	86400 (24 h)	30 days	The workspace ceiling for delegated-scope (OBO) lifetimes. A delegation request above the ceiling is refused with a 400 that names the limit.
AGENTIC_DEFERRED_DECISION_TTL_HOURS	168 (7 days)	720 h	How long a recorded deferred-activation decision waits for the agent’s next run before it shows Expired.
AGENTIC_NOTIFY_ENABLED	true	-	false parks delivery: registration e-mails stay queued and this gateway process sends none of them.
AGENTIC_NOTIFY_SWEEP_INTERVAL	60s	10 m	Outbox sweep interval (minimum 15 s).
AGENTIC_NOTIFY_WORKERS / AGENTIC_NOTIFY_SEND_TIMEOUT	2 / 10s	8 / 60 s	Concurrent sends per process and the per-message SMTP timeout.
AGENTIC_NOTIFY_MAX_PER_REGISTRATION_PER_HOUR	6	100	Storm guard: how many e-mails one registration may queue for one recipient per hour.

Registration e-mails are sent from the platform no-reply mailbox (SMTP_FROM_EMAIL) through the platform SMTP_* settings, like every other platform e-mail; there is no separate sender to configure. While SMTP is not configured the messages stay queued and are sent once it is. See Registration notifications.

Leave the OBO ceiling at its default in production: a standing grant of one human’s authority to an agent should be short-lived. See delegation lifetime and renewal for keeping long-running environments current without widening the window.

Next steps

• Agent Enrolment: per-class enrolment rules, re-enrolment after a denial, and control-plane tokens for CI.
• Agent workload identity: verified agent tokens, accepted token lifetimes, replay protection, and DPoP.
• Registration notifications: what the developer and the administrators receive by e-mail, the two-run route, and the platform no-reply sender.
• Relationship Authorization - advanced role, resource, action, and delegated-access modeling.
• Agentic Observability - investigate runs, decisions, trends, and optional telemetry export.
• Connect MCP servers: transports, authentication, health checks, and tool discovery.
• MCP tool execution: run an authorized MCP tool through the gateway.
• Virtual keys: create and manage workspace credentials.
• Python SDK Agentic governance: enforce decisions at supported framework and tool boundaries.