Parker Portal / The management experience
Give people a place to start. Give administrators a place to manage. Parker Portal brings self-service access, model configuration, identity controls, and usage visibility to the AI workflows you run through Parker.
The role of the portal
Parker Proxy provides the managed path between supported AI clients and model deployments. Parker Portal is the web experience for the people who use and administer that path.
Instead of making every team maintain its own picture of providers, model permissions, and consumption, establish a shared place to configure access and review activity. Users get self-service views; authorized administrators get management tools.
Portal visibility applies to Parker-managed activity. It is not automatic discovery of shadow AI, a replacement for your identity provider, or an assertion that all provider features work identically across clients.
For the people using AI
A usable access model needs more than a URL. Personal views help users understand their available models, manage credentials, and review their own consumption.
Search the account-visible model catalog by name, public ID, or provider and copy the model ID for a supported client.
Use the built-in API reference and downloadable Markdown as setup aids. Catalog discovery is not an access-request or approval workflow.
Create a named personal token, copy its secret once, and use the supplied base URL and Cline guidance to configure a supported client. Inspect last use and revoke a token when it is no longer needed.
This is manual setup assistance, not automatic tool installation or configuration distribution. Individual token policy can differ from the account’s model list.
Review spend, requests, token trends, and per-model usage. Project and session breakdowns are available when clients supply meaningful tags; personal usage includes CSV and JSON download links.
Budget and rate-limit screens show applicable policy, not controls to raise your own allowance. Tagged projects are not managed teams or financial cost centers.
For administrators
Bring model supply, identity policy, and consumption controls into a common administrative experience. Backend authorization remains part of the boundary; hiding a menu is not the security control.
Configure provider connections and credentials, virtual models, and serving deployments. Separate the model identity applications request from the infrastructure that serves it.
Manage users, role mappings, model permissions, and application identities. Review effective access deliberately when introducing a new model or integration.
Configure usage thresholds, rate-limit rules, and Auto-routing settings. Connect the policy discussion to the actual routes and principals being evaluated.
An administrative screen does not imply an approval workflow, automatic least privilege, or universal DLP. Some settings remain deployment configuration. Models without role allow rows can retain default access; user grants and personal-token allow overlays can re-grant access beyond role policy. Validate the effective authorization boundary.
The model lifecycle
The virtual-model workspace connects setup, serving configuration, accounting rates, and access. Applications request a public model ID while administrators manage its upstream backings.
A five-step wizard covers provider and credential selection, upstream model choice, public identity and capabilities, pricing and access, then review. The backend setup operation creates the initial configuration atomically.
Review chat, embedding, image, and audio use cases against supported deployments. A catalog entry does not guarantee every operation works with every provider.
Configure deployment priority, weight, enablement, timeouts, and credentials. Inspect health and recent errors, run a persisted probe, and quarantine or restore a backing.
These are connections to existing inference services, not cloud or GPU provisioning. The simple connection Test can short-circuit for internal deployments; it is not proof of successful inference.
Model drawers bring upstream, routing, pricing, access, and lifecycle controls together. Configure modality-aware rates, cache pricing, and long-context tiers, with lookup and price-history tools.
Configured rates support estimates. They do not synchronize an invoice or guarantee historical request-cost breakdowns use an immutable rate snapshot.
For daily operations
Use recorded request context and aggregate usage to focus the conversation on the affected identity, model, deployment, and time window.
Filter the administrator request explorer by identity, model, client, purpose, and time. Open a detail drawer for recorded deployment, timing, fallback-chain, and cost context, with captured bodies only when available.
The summary strip describes the fetched page, not all matching history. Records are operational evidence, not an immutable administrator-change ledger. Retention requires explicit configuration.
Administrator Usage has Overview, Users, and Service accounts views, with consumption trends, provider/model grouping, client and purpose breakdowns, and audience rankings.
Dashboards are fetched snapshots, not continuous live monitoring. Rankings are bounded, and date-window conventions can differ between views.
Configure daily or monthly user, role, and global budget rules, plus RPM/TPM limits. Signed webhooks can carry budget and rate-limit warnings or breaches to an external receiver.
Budgets use recorded spend, TPM is reactive, and overshoot is possible. The four supported webhook events are not a general notification or native billing system.
Beyond a model catalog
Use the implemented management workflows where they fit. Keep optional and separately hosted experiences distinct instead of treating every backend capability as a portal screen.
Create service accounts with all-enabled-model access or an explicit allowlist, rotate production keys, deactivate accounts, and manage scoped evaluation credentials.
Rotation immediately revokes the previous production key; plan the client cutover. Service identities use their direct access boundary rather than human role mappings.
Register HTTP MCP servers, scope access, configure authentication profiles, inspect connections, review discovered tools and approvals, and manage server routing profiles.
End-user connections are managed in Parker Chat, not the portal’s personal area. A browser connection test is not a complete backend MCP handshake.
Chat Management controls provider groups, model presentation, logos, and prompt buttons. When enabled and authorized, Evaluations supports two-model comparisons using uploaded cases and exact-match scoring.
Chat presentation is not a conversation viewer. Evaluations requires worker and permission setup; it is not an unrestricted benchmarking or human-review suite.
Client-category switches govern recognized application labels, not cryptographic application identity. External tool labels can be inferred from spoofable headers. Use them alongside identity, model policy, and deployment controls, not as an absolute application allowlist.
From screens to operating practice
A useful portal demonstration follows an actual task from configuration to a test request and a review of the result.
Plan a workflow-led demonstrationReview the provider connection, credential, virtual-model definition, and deployment. Test the required client operations, then review access before broad exposure.
Confirm the person’s role mapping or the application’s service identity. Review effective model access, issue the appropriate credential, and validate a request with that identity.
Locate relevant request records, review status and latency, and connect the selected deployment to current configuration. Only inspect captured payloads when storage and access have been approved.
Discuss usage, estimated spend, budget behavior, and support findings with the platform and security owners. Expand only to workflows and data classes that have been evaluated.
Security remains a deployment decision
Configured base Auto request paths support privacy checks and private-data routing. Direct model IDs and auto-plan/auto-code do not run the base Auto scan. History decisions and integration configuration can affect checks.
Do not assume the portal’s usage or request-log screens are a complete DLP incident console. Scanner endpoints, private destinations, attachment limits, and scan-review storage require their own validation.
Optional request/response payload capture defaults off. Other data, including privacy-review image content, can still be retained. Confirm record access, storage, deletion procedures, and backup handling.
Questions, answered
No. It is the management and self-service web experience for Parker-managed access. The proxy handles supported API traffic; the portal helps people configure and operate that access.
No. Personal self-service and administrative management are distinct experiences. Validate both the visible screens and backend authorization using representative user and administrator identities in your deployment.
No. The Users session-revocation action targets the relevant browser authentication sessions; it does not revoke personal API tokens or every desktop credential. Token revocation, service-account actions, and other session types require their own lifecycle handling.
No. The reviewed authorization logic includes default-allow models, user grants, and personal-token allow overlays that can re-grant model access. Group mappings and manual role changes also have login-time behavior to validate. Evaluate the effective policy with real principal and token types before making least-privilege claims.
It centralizes the Parker configuration and operating views described here. Provider account administration, contracts, billing reconciliation, quotas, and provider-specific features may still require the upstream provider’s tools.
No. Model access and data-handling approval are different decisions. Establish policy for model selection, route choice, sensitive content, and destinations; validate the exact workflow instead of treating catalog visibility as a compliance decision.
Operational request records and usage reports can support internal review, but the implementation does not establish complete, immutable compliance evidence. Retention, payload capture, access controls, and external evidence require separate design.
One ordinary user, one administrator, one service identity, a defined model set, and a supported client. Demonstrate discovery, access, a test request, operational investigation, and budget behavior, then document the limits before a pilot.
Bring your operating questions
Walk through Parker Portal with Novacoast using the responsibilities that matter to your team: model onboarding, identity, usage, troubleshooting, and controlled expansion.
Talk to NovacoastParker Portal inquiries
info@novacoast.comUS: (800) 949-9933UK: +44 161 552 2252Portal walkthroughs and evaluation discussions are coordinated by Novacoast’s contact team.
Novacoast