Server and Python SDK 3.2.0

DeepIntShield Server 3.2.0 and Python SDK 3.2.0 - 11 October 2026.

This release aligns the SDK, gateway, and documentation reference at 3.2.0. Check the version and enabled capabilities of your own gateway and worker; a documentation release does not establish what is deployed. The changes keep every 3.1.0 client working: a laptop running SDK 3.1.0 registers exactly as before, without a registrant address, so its developer is not sent a pending receipt.

Registration in two runs

A developer runs the agent with four settings (DEEPINTSHIELD_BASE_URL, DEEPINTSHIELD_VIRTUAL_KEY, DEEPINTSHIELD_AGENT_NAME, DEEPINTSHIELD_REGISTERED_BY) and sees one line:

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

DEEPINTSHIELD_REGISTERED_BY (constructor argument registered_by) is the explicit way to name the registering developer. The gateway maps it to a person in the workspace directory, created just in time when unknown, and notifies it. It is not verified and grants nothing: it is proposed as the accountable owner, which the administrator confirms or changes. One registration keeps its first address; a different address is refused with registration_requester_mismatch. When it is unset, 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, You will be notified at <email>., appears only when the gateway confirmed the address. In Entra gateway mode the first run already submits the SDK’s runtime key, as a Provisional binding when the identity does not exist yet. An administrator who is not the owner completes owner, identity, runtime key, code and tools in one sitting; the next run of the unchanged script executes the whole agent. See Agentic and Microsoft Entra with a local gateway.

Deferred activation

Approve now, activates on the agent’s next run records a decision pinned to the source digest, completed scan, expected-identity declaration revision and the authorized runtime-key binding. The agent’s next attested run applies it before the response; any change in between makes the decision Stale decision · <reason> and re-opens review. AGENTIC_DEFERRED_DECISION_TTL_HOURS (default 168, 1-720) expires unused decisions; Withdraw decision voids one. A recorded decision grants every tool action the reviewer selected, and the Decision recorded card lists the actions that activation will grant, so the next run executes the whole agent; resource permissions and delegations are added after activation. An API client records the same decision by sending defer_activation: true with the review: grant and the optional deferred_grants list (pairs of tool_key and action_key) together name every action that activation grants. Gateways and workspaces that do not use it keep the earlier authorize → run → approve → run sequence. See Deferred activation.

Registration review settings

The Registration review card on the Runtime policy tab of Policy & Access adds Require a separate reviewer for immediate approvals (default off) and Allow VK-trusted approvals (development only) (default on; keep it off in production workspaces). A deferred decision always requires a reviewer other than the accountable owner and other than an administrator who registered the agent with their own sign-in e-mail (approver_conflict_of_interest); control-plane tokens cannot record one (decision_reviewer_unidentified). The review option is labelled Approve as VK-trusted (development only); an Entra provider gains Default for new registrations, and its runtime modes read Gateway exchanges Entra token · recommended and Workload supplies Entra token · Azure-hosted workloads only. Approve as VK-trusted (development only) is offered for every pending registration whose identity is neither proven nor bound, with or without a declared identity. Only an identity that uses gateway exchange can finish a server run. See the registration route by identity type.

Registration e-mails

The gateway e-mails the developer a pending receipt, the recorded decision, the approval or the denial, and e-mails the workspace administrators that a review is needed; a recorded decision that becomes stale is reported to both. Messages 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 and nothing to configure for them. They are written to a durable outbox in the same transaction as the decision, retried with backoff, idempotent, and never on the authorization path. While SMTP is not configured they stay queued and are sent once it is. The pending receipt ends with If you did not register this agent, tell your administrator. and is limited to 20 distinct addresses per reporting key and 20 receipts per address in 24 hours. A per-registration delivery log is available at GET /api/agentic-new/registry/registrations/{id}/notifications. See Registration notifications.

Python SDK 3.2.0

• DeepintShield(registered_by=...), ShieldConfig.registered_by and DEEPINTSHIELD_REGISTERED_BY name the registering developer; the discover payload carries registered_by_email and registered_by_source (explicit or requester). An e-mail-shaped requester is offered only as an advisory hint when registered_by is unset, and requester keeps its meaning: the person the agent acts for.
• New error codes registration_requester_mismatch, credential_host_identity_missing and runtime_binding_identity_missing; agent_registration_pending and agent_runtime_enrollment_pending now read Registration pending. Contact your administrator. The SDK prints the registration line once per process and never a review link; the sentence You will be notified at <email>. is printed only for an address the gateway confirmed. status() returns registration_id instead of a review URL.
• Entra direct mode tries environment variables, workload identity federation and managed identity once each, memoises the failure, and fails fast with credential_host_identity_missing on a host without an Azure identity.
• A pending registration is re-sighted after agent_runtime_enrollment_pending, credential_exchange_failed and credential_host_identity_missing.
• A server-managed submission carries the registering e-mail in its manifest.
• New code managed_gateway_runtime_required: in a workspace listed for server runs, an agent whose identity cannot use gateway exchange is told so: Server runs in this workspace need an agent identity that uses gateway exchange. Please contact your administrator. Where server runs reach every workspace, such a program runs on the developer’s machine instead.
• An agent approved as VK-trusted runs on its virtual key, also when an identity is still declared for it under a provider with gateway exchange.

Deployment

Registration e-mail adds nothing to a deployment: no variable, secret or template value. It uses the platform SMTP_* settings the gateway already has on Cloud Run, Kubernetes and the local compose stack. python3 deployment/restart-local-gateway.py --mail-sink starts a local Mailpit sink that receives all platform e-mail of that dev stack at http://127.0.0.1:8025. The Cloud Run deployment script no longer treats digest-resolved sidecar images as configuration drift.

Upgrade

python -m pip install --upgrade "deepintshield==3.2.0"
# with gateway runtime authentication and LangGraph:
python -m pip install --upgrade "deepintshield[runtime,langgraph]==3.2.0"

The console ships inside the server image, so Server 3.2.0 and its UI upgrade together. API clients must not send the new review fields defer_activation and deferred_grants to an older gateway, which rejects unknown fields. Registrations that were already pending keep working: they carry no registrant and no recorded decision, and the administrator can finish them with either route. Set DEEPINTSHIELD_REGISTERED_BY on every developer laptop and CI runner that registers agents. Registration e-mails need no configuration of their own: they are sent from the platform no-reply mailbox as soon as the gateway’s platform SMTP settings are in place. See Registration notifications.