What does a host policy agent distinguish about an intruder's session that a segment boundary cannot, and what does it cost to run?
answer
- the same flow seen from two places
- off-box sees a header, on-box sees a program
- program is not person
- count the agents you must own and upgrade
basics
~20 sOn the wire the session is just an allowed address pair; on the workload an agent can tie the rule to the process that opened it. It still cannot see who drives that process, and it must run everywhere.
solid answer
~50 sA boundary off the box sees a five-tuple and matches it against a rule. An agent on the workload sees the connection as a local process opening a socket, so its rule can name that program and a handful of named peers rather than a subnet; a shell or a tool the intruder brought is refused even though the address pair is allowed. What it cannot resolve is an intruder executing inside the permitted process with the permitted service-account session, because the rule binds to the program, not to whoever drives it. The prices are real: an agent owned and upgraded on every workload, gaps on platforms that cannot take one, a policy set far larger to review than a dozen zone rules, a fail-open or fail-closed choice per host, and enforcement running on the machine the intruder already controls.
go deeper
Know that some policy is enforced by a device in the path and some by software on the machine itself, and that the second one can see which local program opened a connection while the first cannot.
Explain the vantage difference precisely and state its limit: binding a rule to a process narrows who may originate a flow, but says nothing about who is driving that process.
Be ready to cost a rollout: agent coverage across operating systems, the gaps that cannot take one, policy volume and review, and the fail-open or fail-closed posture you chose and why.
Argue whether the estate should carry per-workload policy at all. The decision turns on who will own thousands of allow statements for years, not on whether the vantage is better.
## Two vantages on the same connection The same batch-tier-to-database connection looks different depending on where you stand. | Vantage | What it observes | What it can therefore refuse | | --- | --- | --- | | Boundary off the box | Source and destination address, port, direction, connection state | Anything whose address pair or port is not on the list | | Agent on the workload | The local process opening the socket, plus the peer it is opening to | A connection from any other program on that host, even to an allowed peer | That difference is the honest case for host-based enforcement, and it is narrower than the pitch usually made for it. Moving the enforcement point onto the workload does not create a new fact about the session's driver. It creates one new fact: which local program originated the flow. ## What that buys against an intruder It buys a genuine narrowing. In a payments back-office fabric where the batch tier legitimately talks to the database tier, a boundary rule permits any process on any batch host to open that port. The agent's rule permits the batch process and refuses a tool an intruder brought with them, an interactive shell, or a second service co-resident on the same host. It also lets the allowed set be a handful of named peers instead of a whole tier, which is where most of the destination subtraction actually comes from. ## What it does not buy, and this is the point of the leaf If the intruder is operating inside the permitted process, or is running the same job with the same directory-authenticated service-account session, the agent allows the flow for the same reason the boundary did. The rule matched the program it was written for. Program is not person, and workload is not session-holder. The reach removed is still the destinations you deleted; the authority is still untouched. An answer that presents host-based policy as the fix for credentialled movement has missed the distinction the interviewer is testing. There is a second limit worth stating: enforcement now runs on the machine the intruder already stands on. An intruder with administrative control of that host is in a position to interfere with the local enforcement point in a way they never are with a filter that sits off the box. That is not a reason to reject host enforcement, but it changes what you may claim about a host you already believe is compromised, and it argues for policy pushed from off-box plus alerting when an agent stops reporting. ## The bill - **Coverage.** An agent must be packaged, installed, owned and upgraded for every operating system in the estate. Appliances, managed database platforms and anything you do not control the base image of will not take one. Every gap becomes either an implicit allow or a broken flow, and both belong in the written statement of what still reaches what. - **Volume.** A dozen zone rules become thousands of small per-workload allow statements. The review burden, not the enforcement, is what usually kills these programmes. - **Failure posture.** Each host needs a decided behaviour when the agent cannot reach its policy source or fails outright. Fail-closed in a payments fabric is an outage; fail-open is a control that quietly is not there. The choice is per estate and it must be written down, not defaulted. - **Change coupling.** Policy is now bound to how applications are deployed. A rebuilt host, a renamed binary or a new release path breaks rules that a subnet-level filter never noticed. ## How to present it in an interview Say what the vantage adds, say precisely what it does not, and price it. The strong answer is: it moves the rule from *this subnet may reach that subnet* to *this program may reach these peers*, which subtracts far more destinations per rule than a zone model can; it does not tell you who is driving the program, so an intruder inside a valid session still passes; and the cost is agent coverage, a much larger policy set to review, a failure posture per host, and an enforcement point sitting on a machine you may not trust.
- Where can a host agent not help at all in this estate?On anything you cannot install it on: appliances, managed database platforms, vendor boxes, hosts on an unsupported operating system. Those destinations are enforced only from the other end, if at all, and the gap has to appear in the written reach statement. Mixed coverage means the statement has holes, and holes you have not named are the ones a board will find.
- If the intruder already has administrative control of the workload, what is the agent still worth?Less than the pitch suggests. Enforcement runs on their machine, so treat the local decision as unreliable for that host and lean on the off-box boundary for anything you must be able to claim. What the agent still gives you is policy pushed from elsewhere, and a signal when it stops reporting or its policy diverges. Do not sell it as containment against a host-level intruder.
- Why is per-workload policy a heavier review burden than a zone model?Because the count explodes and the meaning localises. A zone rule is read once by an architect; thousands of per-workload allows are read by nobody unless you build ownership, expiry and a periodic re-attestation into the process. Without that the set only ever grows, and a policy that only grows converges on permissive.
saying these in an interview costs you the question
- Claims host agents stop credentialled lateral movement
- Treats a process-bound rule as verification of the caller
- Ignores that enforcement now runs on the compromised host
- Assumes every destination in the estate can carry an agent
- Leaves the fail-open or fail-closed choice undecided