Cognizant Technology Authentication

generated: '2026-09-05'
method: searched
source: >-
  https://github.com/cognizant-ai-lab/neuro-san/blob/main/README.md +
  https://github.com/cognizant-ai-lab/neuro-san/blob/main/docs/mcp_service.md +
  openapi/cognizant-technology-neuro-san-agent-service.json
docs: https://github.com/cognizant-ai-lab/neuro-san#readme
note: >-
  HEADLINE FINDING, recorded plainly: the published NeuroSan OpenAPI declares NO
  securitySchemes and applies no security to any of its four operations, and the MCP service
  documentation shows unauthenticated curl calls carrying only Content-Type and
  MCP-Protocol-Version headers. The contract as published describes an OPEN surface.
  That is not the whole picture, and the difference matters. Neuro SAN is self-hosted
  software, so the deployment boundary — not the contract — is where an operator is expected
  to put authentication. The provider does document two real, first-party authorization
  mechanisms in prose, neither of which appears in the machine-readable contract. Both are
  listed below as documented-but-unspecified so an agent author knows they exist and knows
  they cannot be discovered from the spec.
schemes: []
schemes_note: >-
  Empty by observation, not by omission. components.securitySchemes is absent from the
  published OpenAPI and no top-level or operation-level `security` block appears.
documented_but_not_in_contract:
- name: per-user authorization for agent networks
  kind: external-authorization
  source: neuro-san README feature list
  detail: >-
    "per-user authorization for Agent Networks - optional implementations include: OpenFGA".
    An optional, pluggable authorization layer the operator wires in. Not described in the
    OpenAPI, so an agent cannot discover whether a given deployment enforces it.
  enforced_by: operator
- name: Bring-Your-Own-Key (BYOK)
  kind: client-supplied-credential
  source: neuro-san README feature list
  detail: >-
    "Secure Bring-Your-Own-Key (BYOK) support for client-provided API keys so your deployments
    do not have to shoulder everyone else's token costs." These are LLM-PROVIDER keys
    (OpenAI and similar) that the caller supplies, not credentials for the neuro-san API
    itself — an important distinction. They travel over the private sly_data channel rather
    than an Authorization header, which is why they never surface as a securityScheme.
  enforced_by: client
  transport: sly_data (private channel, deliberately excluded from the LLM chat stream)
  evidence: >-
    neuro_san/registries/music_nerd_pro_sly_api_key.hocon and the paired test fixtures
    (tests/fixtures/music_nerd_pro_sly_api_key/{no_user_api_key,with_user_api_key}.hocon)
    are the provider's own worked examples of an agent network that takes a user-supplied API
    key through sly_data.
server_side_credentials:
  note: >-
    The credentials an OPERATOR must set to run a server are environment variables for
    downstream LLM providers, not credentials for this API.
  environment_variables:
  - OPENAI_API_KEY
  - AGENT_TOOL_PATH
  - AGENT_MANIFEST_FILE
  - PYTHONPATH
oauth2: false
openid_connect: false
mutual_tls: false
api_key_header: null
transport_security:
  https_enforced: false
  detail: >-
    The provider's own documented examples use http://localhost:8080. TLS termination is the
    operator's responsibility; nothing in the contract or docs requires it.
agent_guidance: >-
  An agent integrating with a neuro-san deployment cannot learn the auth model from the
  contract and must ask the operator. Assume no authentication is declared, expect the
  deployment to sit behind whatever the operator put in front of it, and expect any
  LLM-provider key to be passed through sly_data rather than a header.