Security and Sandboxing

The compiler can disable categories of built-in functions at compile time. Restricted functions are not lowered into the program at all — calls to them produce "undefined function" compile errors. There is no runtime overhead.

Security Flags

--sandbox

Enables sandbox mode, which disables all potentially risky operations:

Example:

osprey program.osp --sandbox --llvm

Granular Security Flags

For more granular control, you can disable specific categories of operations:

Examples:

# Disable only HTTP operations
osprey program.osp --no-http --compile

# Disable HTTP and WebSocket operations
osprey program.osp --no-http --no-websocket --run

# Disable file system access only
osprey program.osp --no-fs --llvm

Blocked Functions by Category

HTTP Functions

When HTTP access is disabled (--no-http or --sandbox), these functions are unavailable:

WebSocket Functions

When WebSocket access is disabled (--no-websocket or --sandbox), these functions are unavailable:

File System Functions (Future)

When file system access is disabled (--no-fs or --sandbox), these functions will be unavailable:

Third-Party C Libraries (FFI)

Database access is not a hardcoded builtin category. Osprey reaches SQLite (and any C library) through the generic FFI / interop layer — extern fn declarations bound to the linked library (see Foreign Function Interface). It is therefore gated by --no-ffi (PermissionFFI), exactly like any other foreign call. When FFI is disabled, extern declarations and any library they bind (e.g. libsqlite3) are unavailable; no DB-specific permission exists.

Compiler Output

When restrictions are active the compiler prints a summary line:

Security: SANDBOX MODE - All risky operations disabled
Security: Allowed=[FileRead,FileWrite,FFI] Blocked=[HTTP,WebSocket]

Restrictions cannot be bypassed by the compiled program; the relevant runtime functions are never linked in.