Social Engineering Agents — Manus.im
2026-10-02
What an agent skill that exposes a Manus sandbox over SSH and VNC reveals about instructions, delegated authority, and trust boundaries.
When an agent can do more than answer
As I have been building and testing agent workflows, one question keeps coming up for me: what happens when an agent can do more than answer? Give it tools to inspect files, run commands, install software, or reach external services, and the security question becomes what those instructions can persuade it to do with the permissions it already has.
I built manus-expose-endpoints for one specific, explicitly requested job: setting up temporary public SSH and VNC access to the current disposable Manus Linux sandbox. I wanted the workflow to be understandable and bounded, so the skill, setup script, and watchdog each have distinct roles. I use it here as a case study in delegated permissions—not as proof that Manus was exploited, a billing control was bypassed, or somebody else’s account can be reached.
What the repository actually does
In the skill I wrote, the setup script prepares local services and forwards them through bore.pub, a TCP relay. This is not a direct inbound connection to the sandbox: local bore processes establish outbound connections to the relay, which assigns public TCP ports and maps traffic back to the sandbox services.
The two forwards are separate:
- SSH: the sandbox's local port
22is forwarded through abore.pubport. - VNC: the existing local VNC service on port
5900is forwarded through a differentbore.pubport.
The assigned public ports are dynamic. They can change after a reconnect or a new setup, and the endpoint only lasts while the sandbox, local services, relay, and network path remain available. A screenshot or a previously printed port is not proof that an endpoint is still live.
How the agent workflow is put together
The repository has three important pieces: SKILL.md describes when and how the agent should use the capability; scripts/setup-public-ssh.sh performs setup; and scripts/public-ssh-watchdog.sh monitors the tunnel services. In broad strokes, the workflow:
- Checks that setup is being run with root privileges and installs required utilities or the
boreclient if needed. - Configures the local SSH daemon for root login and password authentication, creates a random root password if one is not already stored, and checks that SSH starts.
- Verifies that a VNC listener already exists on local port
5900; it does not create the Manus-managed desktop service. - Creates separate systemd services for the SSH and VNC tunnels and starts them through the relay.
- Starts a watchdog and waits for the tunnel logs to show both assigned public ports before reporting connection details.
Systemd owns the tunnel processes, rather than a loose background shell. The watchdog checks the two named tunnel units on a ten-second interval. It asks systemd to restart a unit if that unit is inactive; for an active unit, it checks the main PID and command line and logs unexpected states rather than killing arbitrary processes. The watchdog does not keep the cloud sandbox alive: provider shutdown, session replacement, relay outages, or external network failures can still end access.
That separation matters. The skill is an instruction layer; the setup script makes local configuration changes; systemd supervises the processes; and bore.pub supplies the public relay. Each layer has its own permissions, failure modes, and trust assumptions.
Is this “social engineering”?
Social engineering usually means manipulating a person into taking an action. With an agent, the analogous concern is that an instruction, prompt, or imported skill might persuade the system to use its delegated tools in a way the user did not intend. A model that can run privileged commands is a meaningful security boundary: instructions that cause it to change authentication settings or publish a service deserve careful review.
But labels should not replace evidence. The repository documents an intentionally invoked skill for remote access to the current sandbox. By itself, it does not show that Manus accepts the skill without user choice, that its controls were bypassed, that an unrelated sandbox can be reached, or that access persists after the sandbox ends. The repository includes an image caption about a session continuing after credits are exhausted; that is an observation about a depicted session, not proof that the skill bypasses billing, guarantees continued access, or can prevent provider shutdown.
The more general lesson is about delegated authority: an agent can make risky changes when it has the tools and permissions to do so. A skill should be reviewed like executable operational guidance, not treated as harmless text merely because it is written in natural language.
The security trade-off: convenient access, public exposure
The README is unusually direct about the main risk. The SSH configuration enables root authentication with a password. The password is randomly generated and written to a file with restrictive permissions, but root login over a public endpoint is still a high-impact exposure. VNC authentication depends on how the existing desktop service was started and may be absent; if it is unauthenticated, the public endpoint can amount to publishing the sandbox desktop to the internet.
The relay obscures the need for direct inbound connectivity; it does not make the forwarded services private. Anyone who obtains a live host and port may be able to attempt a connection. A strong generated password is not a substitute for minimizing exposure, limiting who receives endpoint details, and closing the tunnels as soon as they are no longer needed.
For that reason, the project explicitly describes this as short-lived access to a disposable sandbox—not a production remote-access service, permanent server, or VPS replacement. It warns against using the setup with private keys, API tokens, cloud credentials, session cookies, personal information, or other sensitive data. Even logs, shell history, applications bound to public interfaces, and the visible desktop can reveal information.
Safer operating principles
- Use public SSH/VNC only when you intentionally need it and are authorized to expose the sandbox.
- Assume VNC is public unless the setup explicitly reports that authentication is configured; do not invent or assume VNC credentials.
- Keep generated SSH credentials private, and do not paste connection details into public issues, screenshots, repositories, or logs.
- Keep sensitive files and credentials out of the sandbox while an endpoint is active.
- Verify the current local listeners, service status, and latest assigned ports; a local service being up does not prove the public route works.
- Stop only the skill-owned tunnel and watchdog services when finished, and remember that the provider can terminate the sandbox independently.
Takeaway
manus-expose-endpoints demonstrates how an agent skill can translate a natural-language request into privileged system configuration and temporary network exposure. Its technical mechanism is understandable: local SSH and VNC services, systemd-managed tunnel clients, a public TCP relay, and dynamically assigned ports. The security story is equally clear: successful access is not the same as safe access, and an agent's ability to execute instructions should be bounded by explicit user intent, least privilege, careful secret handling, and a prompt shutdown path.
That is the useful “social engineering agents” question: not whether the agent can be talked into magic, but whether its instructions and permissions are designed so that a persuasive request cannot quietly cross a boundary the user never meant to cross.
Project files
SKILL.md— agent-use guidance and operational cautions.scripts/setup-public-ssh.sh— tunnel and local service setup.scripts/public-ssh-watchdog.sh— narrow systemd tunnel watchdog.- README — architecture, security warning, monitoring, and shutdown notes.