Deny production access. Observe in isolation.

What is cyber deception?

Cyber deception places instrumented decoys where suspicious interaction can reveal behaviour worth investigating. A honeypot is one form: a synthetic system or service created for observation. Decoy files, tokens and endpoints can serve a related purpose.

These techniques already exist in established security products. Remedy’s proposed role is to connect the resulting evidence with device, session, network and incident context, then apply a bounded policy response. A decoy does not replace prevention, segmentation or investigation.

Production denial comes first

Unauthorised access must fail at the production boundary regardless of whether deception is enabled, healthy or available. Policy may then select some suspicious traffic for an isolated deception environment. It should not blindly redirect every blocked request.

Consider an unknown source trying to reach a private database service. The production route is denied. If policy permits, the source may encounter an isolated synthetic service. Any interaction becomes evidence; the synthetic environment contains no production data, usable credentials or route into the real database. This example describes defensive behaviour, not a public scanning or attack service.

An explicit separation of trust

The Deception Zone is designed to have no route back into production, no production-management authority and no real customer authoritative data. Synthetic resources need separate administration and constrained communications. Evidence collection must not create a new path by which an untrusted decoy can command production systems.

A failed or compromised decoy should remain disposable. Resource limits and lifecycle controls are necessary so observation does not become an uncontrolled operational dependency. The architecture needs validation of this separation before a customer relies on it.

• Synthetic services, service banners and administrative interfaces only.
• Synthetic files and records, without confidential production content.
• Decoy credentials and tokens with zero legitimate production privilege.
• Separated evidence handling and no shared production trust.

Tripwires with no useful privilege

A decoy credential is valuable as a signal precisely because ordinary employees and applications should never need it. Attempted use can contribute to an investigation. It must not be a real credential copied into a trap, nor a path that accidentally grants useful access.

An illustrative response is to record the event, reassess related device or session risk, restrict appropriate authority and escalate an incident. The response must remain within tenant policy and supported enforcement capability. A strong signal still needs provenance and context before making a consequential attribution.

Correlate observations rather than count isolated alerts

A new IP address may mean ordinary travel. A new device identity combined with failed posture, repeated step-up failures, unusual peer connections and decoy interaction is a different evidence pattern. The Trust Graph is intended to preserve these relationships.

An operator should be able to see what touched the decoy, when it happened, which policy applied and what was restricted. Raw observations and inferred conclusions should remain distinguishable. Source addresses alone do not reliably establish who is responsible.

Defensive observation, without retaliation

Remedy Deception does not hack attackers back or attempt to compromise external systems. Its boundary is production denial and observation of interaction with isolated synthetic resources under the customer’s control.

Deception routing, decoys, correlation and integrated response are planned capabilities. Their effect depends on placement, network policy, isolation and operational handling. Ask for a technical walkthrough of the intended boundaries and acceptance evidence rather than assuming a live deployment from this architecture page.