diff --git a/public/hal_neverallows.te b/public/hal_neverallows.te
index 61b15cab24837625cf99419b182c1ed9d0b05f64..130a8f6910bd117b322a5a7f205cc9544f1c659e 100644
--- a/public/hal_neverallows.te
+++ b/public/hal_neverallows.te
@@ -17,3 +17,36 @@ neverallow {
   -hal_wifi_supplicant_server
   -rild
 } domain:{ tcp_socket udp_socket rawip_socket } *;
+
+###
+# HALs are defined as an attribute and so a given domain could hypothetically
+# have multiple HALs in it (or even all of them) with the subsequent policy of
+# the domain comprised of the union of all the HALs.
+#
+# This is a problem because
+# 1) Security sensitive components should only be accessed by specific HALs.
+# 2) hwbinder_call and the restrictions it provides cannot be reasoned about in
+#    the platform.
+# 3) The platform cannot reason about defense in depth if there are
+#    monolithic domains etc.
+#
+# As an example, hal_keymaster and hal_gatekeeper can access the TEE and while
+# its OK for them to share a process its not OK with them to share processes
+# with other hals.
+#
+# The following neverallow rules, in conjuntion with CTS tests, assert that
+# these security principles are adhered to.
+#
+# Do not allow a hal to exec another process without a domain transition.
+# TODO remove exemptions.
+neverallow {
+  halserverdomain
+  -hal_dumpstate_server
+  -rild
+} { file_type fs_type }:file execute_no_trans;
+# Do not allow a process other than init to transition into a HAL domain.
+neverallow { domain -init } halserverdomain:process transition;
+# Only allow transitioning to a domain by running its executable. Do not
+# allow transitioning into a HAL domain by use of seclabel in an
+# init.*.rc script.
+neverallow * halserverdomain:process dyntransition;