> 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/engineering-guide/06-bring-your-own-agent.md). # Bring Your Own Agent [← Paper trading](/nytshift-docs/engineering-guide/05-paper-trading.md) · [Documentation home](/nytshift-docs/start-here/readme.md) · Next: [Execution and reconciliation →](/nytshift-docs/engineering-guide/07-execution-and-reconciliation.md) Bring Your Own Agent (BYOA) is the local AgentOps boundary for an MCP-capable agent and model subscription chosen by the human account owner. NYTSHIFT does not resell the model, collect provider credentials or treat a model brand as authority. It supplies governed tools, typed evidence and durable scopes while the human account owner retains every capital decision. The current release is issued by a NYTSHIFT platform operator and is loopback-only. Hosted customer self-service connection issuance is not available. The deterministic **Market Brief** is a first-party product surface. It is not labelled Copilot and is not represented as model-generated. ## Platform split ```mermaid flowchart LR C[Human-owned agent] -->|MCP 2025-11-25| G[NYTSHIFT MCP gateway] G --> ID[Operator-issued expiring identity] ID --> SC[Tool + market + account scopes] SC --> R[Research + activity reads] R --> E[Scoped evidence] SC --> P[paper.v1] P --> L[Simulation ledger] SC --> T[Advisory proposal] T --> H[Optional later human review] H --> A[Fresh server context + AEGIS] C -->|Separate DPoP testnet API| D[Testnet policy + fresh AEGIS] D --> S[Isolated Hyperliquid testnet signer] ``` Research and portfolio-risk tools return evidence without running AEGIS. Agent PAPER applies its own immutable simulator and risk-policy checks. A later human review rebuilds fresh server-owned context and runs AEGIS independently. MCP is not a signer proxy. Testnet automation remains a separately versioned sender-constrained API, and no mainnet agent authority mode exists. ## Connection model An authenticated NYTSHIFT platform operator issues a local connection through the operator terminal's Agent Command Center, which can inspect and revoke issued identities. The customer AgentOps workspace does not currently expose MCP issuance or credential management. Each connection binds: * a maximum 24-hour expiry; * an exact MCP gateway capability mode; * exact MCP gateway tool scopes; * allowlisted market symbols; * zero or more exact venue/account pairs; * quota and budget limits; * immutable paper policy when paper mode is selected; * one-time client secret, retained only as a digest; * individual and global revocation state. Authorization is rebuilt from durable state on every MCP gateway tool call. MCP session IDs carry transport state only. 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`. The connection contract requires `proposal:read` whenever creation is enabled and keeps proposal-write and PAPER-write authority on separate connections. 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 is sent to the separate lifecycle store; a lifecycle rejection is recorded separately. Neither policy authorization nor lifecycle acceptance grants execution authority. A valid signed Agent Pro entitlement is required before issuance. It limits credential capacity and proposal usage, but does not prove payment or grant signer authority. ## MCP v1 tools | Tool | Required scope | Result authority | | ---------------------------------- | ------------------------------------------- | -------------------------------------------------------------------------- | | `nightshift.get_market_context` | `market:read` + allowed symbol | Fresh normalized market evidence; no execution | | `nightshift.get_account_context` | `account:read` + exact venue/account | Redacted account summary; no provider identifiers | | `nightshift.get_portfolio_risk` | `portfolio-risk:read` + exact venue/account | Deterministic completeness/concentration evidence; not an execution review | | `nightshift.create_trade_proposal` | `proposal:create` + proposal mandate | Durable advisory registration only | | `nightshift.get_proposal_status` | `proposal:read` | Credential-owned quota/lifecycle codes | | `nightshift.list_agent_activity` | `activity:read` | Credential-owned bounded audit events | Paper mode adds a separately named surface: | Tool | Required scope | Result authority | | ----------------------------------- | -------------- | -------------------------------------------- | | `nightshift.paper.v1.start_session` | `paper:write` | Connection-owned exact ledger | | `nightshift.paper.v1.place_order` | `paper:write` | Fresh-book simulation under immutable policy | | `nightshift.paper.v1.get_session` | `paper:read` | Calling connection's ledger/risk state only | There are no submit, cancel, retry, sign, transfer, fund, withdraw, policy-edit or arbitrary HTTP tools. ## Research and privacy Public market data still passes through symbol scope. Public addresses still require an explicit account grant because sending account context to an external model is a privacy boundary. Tool inputs/outputs are byte bounded and logs exclude tokens, addresses, proposal content, prompts and model responses. NYTSHIFT never asks for OpenAI, Anthropic, Google or other model-provider API keys. Client/provider authentication remains between the customer and their chosen agent runtime. ## Proposal lifecycle ```mermaid stateDiagram-v2 [*] --> Registered: strict proposal accepted Registered --> Reserved: exact review optionally binds it Registered --> Invalidated: owner/operator invalidates Registered --> Expired: validity ends Reserved --> Consumed: confirmation consumes before signer I/O Reserved --> Released: review expires/fails before attempt Consumed --> [*] Invalidated --> [*] Expired --> [*] ``` The durable proposal store retains normalized identity, hashes and lifecycle codes, not the model conversation, assumptions, evidence text or full proposal body. Proposal consumption supplements fresh AEGIS review; it never replaces it. ## Capability modes | Mode | Scope | Capital authority | | ----------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Research | Market and consented account/risk reads | None | | Propose | Research + advisory proposal lifecycle | None; operator approval mandatory | | Paper | Research/activity + immutable paper policy | Simulation only | | Testnet policy | Signed Agent Pro v2 automation add-on plus a separate DPoP-bound Hyperliquid policy | One signer attempt per request ID within the add-on's monthly quota | | Mainnet agent authority | No MCP or automation mode exists | Unavailable | ## Local and hosted transport Loopback HTTP is the implemented local boundary. Non-loopback MCP is mechanically rejected until a separate hosted activation proves OAuth 2.1 authorization-code + PKCE, exact redirect registration, audience-bound short-lived tokens, refresh rotation, TLS, revocation, abuse controls and an external security review tied to the exact release. Static bearer setup is not silently promoted into hosted production authentication. Token passthrough to venues or model providers is forbidden. ## Commercial model The human account owner pays the model provider directly. 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 for Hyperliquid testnet policy binding and carries a separate monthly automation-attempt quota. Entitlements are issued through a manual business process; the repository does not collect payment. Future entitlements may govern more history, quotas and deeper policy features. Plan, payment or entitlement state can never grant execution authority. Normative sources: [agent platform](/nytshift-docs/normative-design/agent-platform.md), [BYOA operations](/nytshift-docs/agents-identity-and-data/bring-your-own-agent.md), [proposal API](/nytshift-docs/agents-identity-and-data/agent-proposal-api.md), [automation](/nytshift-docs/agents-identity-and-data/agent-automation.md) and tickets [NS-438](/nytshift-docs/implementation-ledger/ns-438-byo-agent-mcp-foundation.md) through [NS-442](/nytshift-docs/implementation-ledger/ns-442-agent-production-qualification.md). --- # 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/engineering-guide/06-bring-your-own-agent.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.