One product. Three connected surfaces.
PaloNexus connects the developer SDK, the enforcement Control Plane, and the security Command Center so every agent action is identity-aware, policy-checked, and attributable to the human authority behind it.
One product. Three connected surfaces.
PaloNexus SDK
Give developers and agent owners one integration contract for registration, identity provisioning, scoped requests, and typed allow, deny, or approval-required outcomes.
PaloNexus Control Plane
Operate the policy, identity, delegation, approval, and revocation boundary in the runtime you already run. Kubernetes and supported IdPs are current integrations, not the product definition.
PaloNexus Command Center
Give security administrators and leaders one read surface for fleet posture, identity, approvals, decisions, ownership, and the verifiable authority trail.
PaloNexus deployment paths
Start locally, request access to a hosted team cell, or operate the same Control Plane in your Kubernetes environment. One product, different deployment boundaries.
Why now
The agent ecosystem itself is pointing at the gap: LangChain’s sandbox guidance says to keep credentials outside the sandbox and inject them through an outbound proxy, and OpenAI’s agent architecture keeps authentication and audit outside the workspace. Both name the broker; neither ships it. PaloNexus is that missing layer — it resolves the agent’s owner, task, and delegation, then issues short-lived, scoped access outside the untrusted boundary, so no agent or sandbox ever holds a standing production credential.
Enforce — PaloNexus Control Plane
The SDK registers an agent, provisions its identity, and carries the human, task, action, and resource context into every governed request.
The shipped self-hosted Control Plane verifies identity, evaluates authorization, manages delegation and revocation, and records the decision with fail-closed behavior.
Kubernetes, source control, CI/CD, data platforms, and internal APIs receive only the scoped authority the active policy permits.
Observe — PaloNexus Command Center
When developers govern agents through the PaloNexus SDK and Control Plane, security teams get one read surface over authority — every action answers which agent acted, on whose authority, who approved it, and what policy context applied.
The shipped portal records why, not just what: identity, owner, delegation, policy context, outcome, and expiry are visible alongside the decision.
Each decision record is part of a verifiable audit trail so investigators can distinguish checked evidence from an assertion.
Governed and ungoverned counts, per-agent posture, ownership, and lifecycle revocation make changes visible instead of surprising.
Planned next: Policy Studio for version-controlled policy authoring and deployment.
Works with
Start here
Denied by default. During a live incident (INC-4821 in the demo), an SRE agent requests a production deployment restart. It holds no standing credentials, so the action stops at the decision point.
Owner-verified approval. PaloNexus routes the request to the service owner — and verifies that this person is actually entitled to approve this action on this resource.
Five minutes of scoped access. On approval, the agent receives a short-lived credential bound to that task, that deployment, and that window. Nothing else.
Auto-revoked, fully attributable. Access expires with the elevation window, and the authority trail records the agent, owner, delegation, approver, policy, and credential behind the action.
Human approval across the surfaces
PaloNexus answers the question approval checkboxes skip — was this person entitled to grant this authority? — so security teams can say yes to agents without handing out standing access.
Choose your deployment path