They&#x27;re compatible approaches, you could use pledges in a unikernel for exactly the same reason in order to <i>further</i> reduce the application&#x27;s attack surface: a unikernel includes only what the application needs but it can&#x27;t take advantage of the application&#x27;s needs varying (reducing) over time[0], which is pledge(2) allows.<p>[0] one of the reasons for pledge(2) was the realisation&#x2F;understanding that many applications have an initial setup phase followed by a &quot;stable state&quot;, where the stable state needs significantly less services than the setup e.g. setup might require reading config files but the steady state doesn&#x27;t and just listens on a socket, so you can call pledge(2) multiple times and further reduce the application&#x27;s abilities (attempting to increase them will fail with EPERM)