> It doesn't prevent bad code from USING those secrets to do nasty things, but it does at least make it impossible for them to steal the secret permanently.

Agreed, and this points to two deeper issues: 1. Fine-grained data access (e.g., sandboxed code can only issue SQL queries scoped to particular tenants) 2. Policy enforced on data (e.g., sandboxed code shouldn't be able to send PII even to APIs it has access to)

Object-capabilities can help directly with both #1 and #2.

I've been working on this problem -- happy to discuss if anyone is interested in the approach.

▲

Tomuus an hour ago | parent [-]

Object capabilities, like capnweb/capnproto?

	▲	ryanrasti 2 minutes ago \| parent [-]
		Yes exactly Cap'n Web for RPC. On top of that: 1. Constrained SQL DSL that limits expressiveness along defined data boundaries 2. Constrained evaluation -- can only compose capabilities (references, not raw data) to get data flow tracking for free