As a complete aside, I'm happy that they added "execpromises" to pledge. It was one of the main things that really concerned me about its usage as a sandboxing system (seccomp I think is still more powerful but I will be the first to admit it's ridiculously complicated to get right).
It's possible, but it's fairly hard. You'd need a second process to supervise the seccomp'ed process, watching the paths that it accesses with ptrace, and allows/disallows the actions based on inspection of the process state.
The problem is that seccomp, as far as I'm aware, does not provide you with easy access to the actual arguments of system calls if they are not pointers. The actual pointed-at values of the arguments are required for emulating pledge.
The need for ptrace is soon going to change with the new seccomp userspace notification API (still undergoing review) which allows a userspace process to get notifications when seccomp is tripped and decide what the return code of the syscall is (you can also give it an fd which is copied to the process unix socket style). This would allow you to use process_vm_{read,write}v without the need to mess around with PTRACE_SEIZE.
The main usecase for this is container runtimes (emulating privileged operations like auto-loading of kernel modules), but it could also be used for this an a whole host of other really neat features.
(Huge shout-outs to Tycho Anderson for working on this for quite a while!)
