RED CRICKET PAM

Not a password manager. A protocol-level security proxy.

Privileged Access Management built to isolate real credentials, record every session, and block malicious commands before they reach the server.

  • SSH
  • SFTP · FTP
  • Telnet
  • RDP · VNC
  • MySQL · PostgreSQL
Request a quote

HOW IT WORKS

Real interception, not passive recording

Red Cricket PAM operates as an intentional Man-in-the-Middle between the user and the server, at the protocol level — not a terminal that just watches.

Privileged user

Red Cricket PAM

  • The real credential lives here. The user never sees it.
  • Session recorded end to end
  • A blocked command dies inside the proxy
Target server
  • Native support for SSH, FTP, SFTP, Telnet, and RDP
  • Real credentials isolated from the end user
  • Video recording of every privileged session
  • Detects and blocks malicious commands before they touch the server

IN PRACTICE

Three commands, three outcomes.

connected through Red Cricket PAM · session rc-8f21 · recording

ssh dbadmin@prod-db-01

systemctl restart postgresql

Allowed by policy · executed on prod-db-01

pg_dump --schema-only inventory

No explicit rule · session on hold, waiting for approval

rm -rf /var/lib/postgresql

Blocked · the command never left the proxy

An illustration of policy behavior in an SSH session. The three outcomes — allow, hold, block — are the ones the policy engine resolves.

INLINE APPROVAL

The command nobody saw coming doesn't approve itself.

AI agent — in design

Product vision for assisted privileged remediation. Not available today.

An explicit policy handles what you already know about. Everything else — the command nobody ever wrote a rule for — is exactly where incidents happen. Instead of choosing between blocking everything and letting it through, PAM holds the session and asks for a human decision before it continues.

  1. 01

    A command with no rule arrives

    It matches no allow rule and no deny rule. The session stops right there, and the command never reached the server.

  2. 02

    A request opens

    With the user, the asset, the exact command and the session behind it. None of it is reconstructed after the fact.

  3. 03

    Someone decides

    An approver allows or denies from inside your own network. It doesn't depend on the internet or an external notification.

  4. 04

    The session continues or ends

    The decision and who made it stay in the audit trail, tied to the session that triggered them.

PROTOCOLS

One engine per protocol, not a generic adapter.

Every protocol is intercepted by its own engine, one that understands its format on the wire. That's why policy applies to the actual command, not to an approximate transcript of what the user typed.

SSH

Interactive sessions and remote execution, with policy on every command.

SFTP · FTP

File transfer under the same rules as the interactive session.

Telnet

Network gear and legacy systems that speak nothing more modern.

RDP · VNC

Remote desktop through an embedded terminal in the browser, no client to install.

MySQL · PostgreSQL

Database access intercepted at the protocol, not through an intermediate client.

EVIDENCE, OUTBOUND

Events go out to your SIEM. They don't stay here.

Every command, every approval and every audit event is exported to the tool where you already watch the rest of your operation. Your auditor doesn't have to learn a new console to ask you for evidence.

Splunk

Delivered over HTTP Event Collector.

Elastic

Delivered over the Bulk API.

Syslog

RFC 5424 format, to whatever collector you already run.

The destination is configured per customer from the integrations catalog.

DEPLOYMENT

Three modes, depending on your infrastructure

Standalone

Direct deployment on your existing infrastructure, full control from day one.

Plug-and-Play Appliance

Preconfigured hardware, ready to connect without a lengthy integration project.

Cloud Multi-Tenant

Standard SaaS managed by Red Cricket, for operations that don't require an isolated environment from day one.

THE FIRST STEP

A 30-day pilot, and what you configure stays.

Before you commit to anything long-term, PAM is deployed in your environment over a limited scope, with success criteria we agree on in writing. When the 30 days are up, the evidence is on your side.

  • 30 days across up to 5 assets of your infrastructure
  • A scope letter with success criteria agreed in writing before we start
  • What gets configured during the pilot goes to production as is — the work isn't done twice

Pilot scope and terms are set in the quote.

Quoted by asset count and privileged users — there's no public price list, because every corporate environment is different.

Schedule a technical conversation