Parker Proxy / Governed AI access
Parker Proxy is an identity-aware gateway between supported AI clients and your model providers. Centralize access, apply configurable request-side data protection, and give your teams a governed way to use AI.
A control point in the request path
Conceptual flow. Privacy checks depend on the route and configuration, not simply on passing through the gateway.
The problem
AI adoption can scatter provider credentials, model choices, and sensitive prompts across tools and teams. A written policy is difficult to enforce when every application takes a different path to a provider.
Parker puts supported AI workflows behind a shared gateway. Administrators manage provider connections, virtual models, identity policies, and usage controls in one place, while teams use compatible APIs in their existing workflows.
Parker governs traffic routed through it. Network controls, client configuration, and your wider security program remain essential to managing direct access outside the gateway.
Data loss prevention
Use configurable privacy checks on the base Auto route to help identify sensitive request content before model dispatch. Route flagged requests to an administrator-configured private-data destination.
Text checks combine patterns for selected sensitive identifiers and secrets with a configured AI scanner. Image analysis is available for supported image inputs.
Detectors include dashed Social Security numbers, checksum-qualified payment card numbers, and selected API keys and private keys. Coverage is not universal.
Flagged requests can override the ordinary model choice and use the configured private-data model. An indeterminate scanner result also takes private-data handling.
If an eligible private destination is unavailable, the request fails closed rather than silently using the general default.
Review recorded scan decisions and routing activity to tune policy and investigate unexpected behavior. Choose scanner and destination deployments deliberately.
Private-data model settings alone do not guarantee an on-premises path. Validate scanner hosting, deployment classification, and egress controls.
Know the boundary. These are request-side privacy checks, not response filtering or automatic redaction. Direct virtual-model requests and the auto-plan/auto-code routes do not run the base Auto DLP scan. History-based allow decisions can bypass fresh scans. Attachment inspection has type, size, and extraction limits, and is not an exhaustive scan of every document.
Centralized management
Bring the settings behind AI access into a management portal, with server-side administrative authorization and controls that span providers, people, and operations.
Configure virtual models, provider deployments, credentials, routing policies, and deployment priorities without distributing provider keys to every client.
Manage users, roles, group mappings, service accounts, and model permissions. Configure your identity provider and explicitly review access defaults.
Configure budgets and rate limits. Review model usage, estimated cost, request status, and deployment health to support operational decisions.
Some controls remain deployment settings, and privacy scan review uses a separate administrative surface. Model access is not universally deny-by-default: unconfigured models can retain default access, and user grants or personal-token allow overlays can re-grant access beyond role policy. Validate effective authorization before relying on a role boundary.
Explore Parker PortalSecurity by design, configured with intent
A gateway is a security control point, not a substitute for a secure deployment. Parker provides concrete mechanisms your engineering team can configure and validate.
OIDC authorization-code authentication with PKCE connects sign-in to your IdP. Personal and service-account API tokens support machine access, expiration, and revocation.
API tokens are stored using HMAC-SHA256. Multifactor authentication depends on your identity provider’s policy.
Provider credential storage uses AES-256-GCM encryption. Central credential management reduces the need to place upstream provider secrets in individual clients.
Protecting and operating the encryption master key remains a deployment responsibility.
Request logs capture identity, model and deployment context, status, latency, token usage, and estimated cost on supported accounting paths.
Secret-protected Prometheus metrics support monitoring. Optional payload capture should be evaluated against your data-handling requirements.
Model choice & operational control
Configure category-to-model mappings, capability checks, access filtering, and health-aware deployment selection. Priority tiers and weighted distribution help organize eligible deployments.
Bounded sibling-deployment failover can retry before a response is committed. It is not a guarantee of recovery after a streamed response has begun.
Daily and monthly budgets, rate limits, and price-book-based cost estimates help teams manage usage. Optional caching and context compression add configuration-dependent efficiency controls.
Budgets use recorded spend; concurrent requests may exceed a threshold. Estimated cost is not invoice-exact billing, and Parker does not guarantee a particular savings percentage.
Where it fits
Start with a scoped use case and representative data. Validate both the expected behavior and the failure paths before expanding access.
Connect supported coding clients to approved models through a shared endpoint, rather than handing out individual provider credentials. Validate which client routes run privacy checks.
Test selected sensitive-data patterns and configured scanner behavior, confirm the flagged-content route, and verify the actual infrastructure processing the content.
Bring users, model permissions, budgets, and usage reporting into a common operating model for platform, security, and engineering teams.
Questions, answered
No. Configured base Auto request paths support privacy scanning. Direct virtual-model access and auto-plan/auto-code do not run that base scan. Parker does not provide general response-side DLP. Scope supported clients, routes, attachments, and history overrides as part of your rollout.
No general redaction, masking, or tokenization engine is claimed here. The privacy workflow changes routing for flagged content, or rejects a request when required processing or a suitable private destination is unavailable.
Yes. Parker supports internal and external model deployments. Validate the configuration and hosting of both privacy scanners and private-data models before making data-residency commitments. A private-data label alone is not a network guarantee.
Operational logging and optional request/response payload capture need deliberate configuration. Payload capture is off by default, but privacy review can retain content such as flagged image bytes. Do not assume zero retention or automatic privacy-history expiration.
No. Its controls can support a governance program, but compliance depends on the complete deployment, policies, evidence, and your organization’s obligations. Validate requirements with security and legal teams.
Choose a small group, a supported client, a defined model set, and representative test cases. Verify identity, scanning scope, private routing, failure handling, usage reporting, and operational ownership with Novacoast before broad deployment.
A practical next step
Talk with Novacoast about your AI clients, sensitive-data requirements, model providers, and the operational boundaries your team needs.
Talk to NovacoastParker Proxy inquiries
info@novacoast.comUS: (800) 949-9933UK: +44 161 552 2252Demo requests and deployment discussions go to Novacoast’s contact team.
Novacoast