> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/normative-design/agent-platform.md). # AgentOps and Bring Your Own Agent platform ## Product boundary NYTSHIFT is the governed market, proposal and risk-control layer between an external agent and any separately reviewed capital action. It is not the model provider. The human account owner chooses an MCP-capable agent and pays that provider directly; NYTSHIFT supplies typed tools, durable policy and bounded activity evidence. The current MCP release is platform-operator-issued and loopback-only. The operator terminal's Agent Command Center issues, inspects and revokes MCP connections. The customer AgentOps workspace currently inspects proposal-token mandate, quota, expiry and authority, not MCP connection secrets or controls. Hosted customer self-service authorization, a unified Flight Recorder and Strategy Passports are next product layers. ``` human-owned agent and subscription | +-- MCP research/activity --> scoped evidence | +-- MCP proposal ----------> durable advisory record | | | +--> optional later human review | + fresh server context + AEGIS | +-- MCP paper.v1 ----------> deterministic simulator + paper ledger | +-- separate DPoP testnet API --> testnet policy + fresh AEGIS | +--> isolated testnet signer ``` All research tools return scoped evidence only. The portfolio-risk response explicitly reports `aegisEvaluation: not-run`. Agent PAPER uses its own immutable simulation policy. Neither is a disguised precursor to venue authority. The model never receives a venue private key, wallet key, signer credential, operator cookie, CSRF token, license token or unrestricted internal API token. MCP is not a signer proxy. ## Capability modes A valid signed Agent Pro entitlement is required before the platform operator can issue any current credential or MCP connection. The entitlement limits credential capacity and proposal usage. It does not grant signer authority. | Mode | Available capability | Capital authority | | ----------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Research | Fresh allowlisted market context and explicitly account-scoped redacted portfolio context | None | | Propose | Research plus strict `TradeProposal` registration and proposal/activity status | None; operator approval remains mandatory | | Paper | Research/activity tools plus deterministic PAPER requests inside one immutable server policy | Local simulation only | | Testnet policy | Signed Agent Pro v2 automation add-on plus a DPoP-bound, maximum-24-hour Hyperliquid testnet automation policy | One policy-bound signer attempt per request ID; no cancel or retry tool | | Mainnet agent authority | No MCP or automation mode exists | Unavailable | No mode is inferred from a model brand, subscription tier, prompt or client declaration. NYTSHIFT derives it from durable server policy on every call. ## MCP v1 tool surface The core MCP v1 namespace is deliberately read/proposal only: | Tool | Scope | Output boundary | | ---------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | `nightshift.get_market_context` | `market:read` plus an allowed symbol | Strict provider-normalized market evidence with timestamps and zero execution authority | | `nightshift.get_account_context` | `account:read` plus an exact venue/address grant | Redacted account summary; no provider order, transaction or client identifiers | | `nightshift.get_portfolio_risk` | `portfolio-risk:read` plus an exact venue/address grant | Deterministic completeness, gross notional, margin and concentration evidence; never an execution review | | `nightshift.create_trade_proposal` | `proposal:create` plus the existing mandate | Existing strict proposal authorization, quota and lifecycle registration | | `nightshift.get_proposal_status` | `proposal:read` | Credential-owned quota and fixed-code lifecycle evidence only | | `nightshift.list_agent_activity` | `activity:read` | Credential-owned bounded fixed-code audit events only | The separately named paper family is also available only when the connection is created in paper mode: | Tool | Scope | Output boundary | | ----------------------------------- | ------------- | --------------------------------------------------------------------------------------------- | | `nightshift.paper.v1.start_session` | `paper:write` | Idempotent connection-owned exact ledger under the immutable paper policy | | `nightshift.paper.v1.place_order` | `paper:write` | One fresh-book simulation result with explicit unmodeled fee, funding and liquidation domains | | `nightshift.paper.v1.get_session` | `paper:read` | The calling connection's ledger, positions and risk-lock state | MCP never publishes submit, cancel, retry, sign, transfer, fund, withdraw, policy-edit or arbitrary HTTP tools. Hyperliquid testnet remains a separate DPoP-bound API handoff rather than bearer authority hidden inside an MCP tool. ## Identity, authorization and privacy * Every current connection is issued by an authenticated NYTSHIFT platform operator, expires in at most 24 hours and is individually or globally revocable. Its client secret is displayed once. * A connection's MCP policy binds exact gateway tool scopes, market symbols and zero or more exact venue/account pairs. Public address data still requires an explicit account grant because sending it to an external model crosses a privacy boundary. * Every current MCP request must use loopback HTTP. Non-loopback requests are mechanically rejected. * Hosted interactive authorization is **NEXT** and must prove OAuth 2.1 authorization code with PKCE, exact redirect registration, audience-bound access tokens, short lifetimes, refresh-token rotation, HTTPS and an independently enabled remote-MCP activation gate. Static bearer setup remains a local/developer path, not the hosted end state. * The `nsp_v1` token format is shared by two credential classes. A proposal-only credential has no MCP policy: it can use the direct advisory-proposal API under its active entitlement, mandate and proposal quotas, but it cannot initialize or call the MCP gateway. An MCP-backed connection carries a durable MCP policy. For an MCP-backed connection using the direct proposal API, status reads require `proposal:read`; submissions require `propose` mode and `proposal:create`. * For an MCP-backed connection, missing proposal mode or scope returns HTTP 403 before any proposal-attempt event, quota or usage mutation, or lifecycle registration. After those checks pass, NYTSHIFT evaluates the proposal and records the authorization result. Only an authorized proposal enters the separate lifecycle store, and neither authorization nor lifecycle acceptance grants execution authority. * Requests, tool inputs and tool outputs are byte bounded. Method names, content types, protocol versions, tool names and JSON keys fail closed. * MCP sessions are transport state only. Authorization is re-evaluated from the durable connection policy on every MCP gateway tool call. * Logs and public health retain opaque connection/tool/result codes, timings and counts. They exclude tokens, account addresses, proposal content, prompts and model responses. ## AEGIS and execution rules * Market and portfolio tools provide evidence, not permission. * Proposal acceptance means only durable advisory registration. * Every later review rebuilds fresh server-owned account, market, fee and portfolio context and re-runs AEGIS. * Paper authority cannot be promoted into venue authority. * Testnet automation continues to require the separately versioned DPoP policy and one-attempt/reconcile-only lifecycle. * No mainnet agent mode exists, and one cannot be activated from the browser, MCP client or model. * Unknown execution outcomes are reconciled by the retained request identity before any new economic action. ## Commercial boundary The human account owner pays the model provider. A signed Agent Pro entitlement currently gates credential issuance, active-credential capacity and proposal usage. The additive signed v2 automation add-on is also required before a platform operator can bind one active credential to a Hyperliquid testnet automation policy, and it imposes a separate monthly automation-attempt quota. Issuance is manual and provider-neutral; the repository does not collect payment. Future entitlements may govern additional history, quotas and deeper policy features. They do not select or resell a model, and model-provider access tokens are never collected by NYTSHIFT. Named pricing tiers, scheduled PAPER, team approval and public strategy licensing are not current claims. An entitlement proves only the signed capability grant described by its payload. It does not prove payment or grant execution authority. ## Activation lanes 1. **Current protocol foundation:** strict MCP contracts, read/proposal/PAPER tools, scoped connection store, bounded activity, health and local client tests. 2. **Current AgentOps surface:** issued identity inspection, exact scopes and limits, activity, expiry and revocation. 3. **Next evidence layer:** unified `PaperRun`, Flight Recorder, strategy version lineage and Strategy Passports. 4. **Next hosted authorization:** customer ownership, OAuth 2.1/PKCE, TLS, managed secret storage, abuse controls and independent security review. 5. **Gated testnet:** the existing direct DPoP testnet automation handoff remains separate from MCP. 6. **Unavailable mainnet authority:** architecture and fail-closed gates may ship, but agent authority remains disabled until every signer, eligibility, reconciliation, alerting and canary prerequisite is independently proven. ## Completion evidence This platform is complete only when each objective has direct evidence: * generated protocol contracts and compatibility checks; * deterministic unit, route, abuse, replay, stale-data and store-migration tests; * rendered desktop/mobile operator Agent Command Center and customer AgentOps workspace verification; * real MCP interoperability tests against at least two independent clients without sharing model credentials (an external hosted-activation artifact, not a claim made by unit tests); * remote OAuth/TLS/security rehearsal evidence bound to the exact release; * paper and Hyperliquid testnet end-to-end receipts, including revocation and ambiguous-result reconciliation; * health, metrics, alerting, backup/restore and operator runbooks; * mainnet gates visibly locked unless their independent evidence is current. The implemented local release includes strict contracts, loopback transport, policy-scoped tools, paper sessions, Command Center control, health, verified backups and automated abuse/replay/store tests. Hosted OAuth, public-origin interoperability, independent security assessment and exact-release production rehearsal remain explicit activation evidence; their absence keeps remote MCP mechanically unavailable. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://nytshift.gitbook.io/nytshift-docs/normative-design/agent-platform.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.