PokeePokee Enterprise API

Offline mode

A locked-down tenant variant for workloads that must not touch the public internet.

A locked-down variant of the Pokee Enterprise API for customers who require the agent to operate without public-internet access. Same REST contract as the standard tenant — same endpoints, same SSE wire format, same auth — but the agent runs inside a sandbox whose only outbound network path is the model completion API.

If your contract includes offline mode, you'll have either an offline-only endpoint or two endpoints — a standard one and an offline one — paired so they share a single credit balance. See Pairing online + offline.

Threat model

Offline mode is designed against:

  1. Data exfiltration via the agent. Even if a prompt convinces the model to call out to an attacker-controlled URL, the network drops the connection.
  2. Unintended third-party API calls. No skill, library, or shell command can reach the public internet at large.
  3. Auditable egress. Every outbound TCP connection passes through one process whose log shows hostname + status, suitable for compliance review.

What it is not: a fully air-gapped environment. The model completion API still egresses to Pokee's inference infrastructure, which sits outside your network. If you need fully air-gapped, the right shape is a customer-side deployment of the gateway image into your own VPC — talk to Pokee.

Network model

Your tenant pod                                              
                                                             
  api-gateway ──▶ in-pod inference router ──┐
       │                                    │ HTTPS
       │ HTTPS_PROXY                        │ allowlisted
       ▼                                    ▼
  egress-proxy (hostname allowlist) ──▶ Pokee inference
  • All HTTPS egress flows through an in-tenant forward proxy with a hostname allowlist. Direct public-:443 from the gateway pod is denied at the network-policy level — the proxy is the only path out.
  • The proxy's allowlist contains only Pokee's inference endpoints by default. Any other destination is rejected.
  • DNS is allowed only to the in-cluster resolver; the cloud metadata server is denied.

Differences from the standard tenant

BehaviorStandard tenantOffline tenant
Public-:443 egressOpenDenied except through the hostname-allowlisted proxy
Skill catalogueAll bundled skills (web search, deep research, web read, …)Local builders only — pdf-builder, pptx-builder, docx-builder, xlsx-builder, pokee-resume-builder
Agent WebSearch / WebFetch toolsAvailableDisabled
Customer file uploads via /v1/sessions/{id}/files/*AvailableSame — file API still works
File-permission scoping (file_access)AvailableSame
Streaming, idempotency, resume, cancelAvailableSame

The REST contract is identical. Code written against the standard tenant works against an offline tenant for any flow that doesn't depend on the disabled skills or tools.

Models

Same model-selection rules as a standard tenant: your contract specifies one default model, and the gateway runs every session on that model unless your deal explicitly enables client-side model selection. Per-token rates for the standardized tiers are documented on the Models and pricing page.

Offline tenants run on the standardized Pokee Isaac tierspokee-isaac-high-reasoning and pokee-isaac. Both are served by Pokee-managed infrastructure; the high-reasoning tier's delegated subagent calls stay within Pokee's own Bedrock egress so no third-party network policy holes are punched. Azure (kimi-k2.6, gpt-5.5) and Vertex (gemini-3.1, gemini-2.5-pro) are deliberately not exposed in offline mode, since those upstreams would require punching new holes that go against the threat model. Additional Bedrock-routed models can be enabled per-deal if your contract explicitly allows.

If your tenant is in single-model mode (the default), the model field on POST /v1/sessions is ignored — every session runs on your contracted default. Talk to Pokee if you need client-side selection across the three tiers.

Pre-installed packages

The agent's sandbox runs Python 3.11 with the following pre-installed. Nothing extra is needed for the agent to import them — they appear automatically in any python3 invocation.

Python

Data: pandas, numpy (transitive), openpyxl

Text & markup: lxml, defusedxml, markdown, markitdown (PDF / DOCX / XLSX / PPTX → markdown; pulls in pdfminer.six, python-docx, mammoth, python-pptx, BeautifulSoup4)

HTTP & async: requests (transitive), httpx, aiohttp, aiofiles, websockets

Imaging: Pillow

PDF: pypdfium2 (read / merge / split / extract / rotate / render), weasyprint (HTML/markdown → PDF)

Time: croniter

Database: asyncpg

System

pandoc, imagemagick (convert, identify, …), poppler-utils (pdftotext, pdfimages, pdftoppm), libreoffice (Writer / Impress / Core — used by docx-builder / pptx-builder), git, curl, wget, unzip, node (Node.js 22) + npm, full GNU coreutils, fonts-noto-* (CJK + emoji), locales (en_US.UTF-8).

Bundled skills

Five document-building skills are pre-loaded and discoverable by the agent without any configuration:

  • pdf-builder — generates polished PDFs (cover letters, reports, proposals, resumes).
  • pptx-builder — generates PowerPoint slide decks.
  • docx-builder — generates Word documents with formatting.
  • xlsx-builder — generates Excel workbooks with formulas, charts, and formatting.
  • pokee-resume-builder — produces resumes conforming to a structured schema.

All five run entirely inside the pod with no external API calls.

Adding packages or skills

If your workload needs a Python package, system tool, or custom skill that isn't on the list above, three options:

1. Pokee bakes it into the shared offline image

Recommended for common dependencies. Email your Pokee account contact with the package name and a one-line description of what the agent needs it for. Pokee adds the package, redeploys, and confirms availability. Typical turnaround: 1–2 business days. No additional cost.

2. Pokee bakes it into a tenant-specific image layer

Recommended for heavyweight or tenant-specific dependencies (large ML libraries, proprietary internal libraries, anything subject to your own licensing). Same request flow, but the package lands only in your image. If the package needs to download data at runtime (model weights from Hugging Face, etc.), the request must include the hostname — Pokee adds it to your tenant's egress allowlist alongside the package.

3. Custom skills via the files API

You can ship arbitrary skills by uploading a directory to your workspace under skills/:

curl -X PUT $POKEE_API/v1/sessions/$SID/files/skills/my-skill/SKILL.md \
  -H "Authorization: Bearer $POKEE_KEY" \
  --data-binary @./SKILL.md

The next session you create has my-skill available alongside the bundled ones. Skill code runs inside the offline sandbox, so it inherits the same network restrictions — your skill can only reach hosts on the allowlist.

Pairing online and offline

Many customers want a standard tenant for general agent workloads and an offline tenant for sensitive ones. We model this as two tenants under the same account, addressed by two different endpoints — your code picks based on the workload:

Standard tenantOffline tenant
Endpoint{tenant}.enterprise.pokee.ai{tenant}-offline.enterprise.pokee.ai
Bearer tokenonea different one
Workspace filesindependentindependent (custom skills must be uploaded to both)
Conversation sessionsindependentindependent
Credit balanceshared (one balance counts down across both)shared
Network and skill restrictionsopenlocked-down per this page

The shared credit balance is opt-in — by default each tenant has its own. Ask Pokee to "make the offline tenant an addon" of your existing one and the credit ledger is configured so a top-up applied to either flows to a single shared pool. GET /v1/usage against either endpoint returns the same balance.

Customer-uploaded skills (via the files API) are not shared between paired tenants — they live on each tenant's PVC. If you maintain a custom skill, upload it to both endpoints when you want it available on both.

Egress audit

Every outbound TCP connection from your tenant is logged at the proxy with the destination hostname, status, and timestamp. Logs can be shipped to a customer-controlled bucket on request — same per-deal contract as the existing usage and audit log exports.

Talk to us

Questions about whether your workload fits the offline shape, package additions, or fully air-gapped deployment options: contact your Pokee account team.

On this page