Context, devices, and risk

Context is evidence

Subject and resource attributes come from systems of record. HR decides Omar's desk, and the rights desk decides an embargo. Environment attributes are different, because nobody decides them. They are observations about one request, made by something the service has to trust, and each comes with its own reliability. The time comes from a clock. The country comes from an IP address. The device's state comes from a management system, and a risk score comes from a system that judged the sign-in.

Where attributes come from asked who is responsible for each attribute. For the environment, the question becomes sharper: who observed this, how, how could the observation be wrong, and what would the rule do if it were?

Time, place, and network

Time looks like the simplest attribute, and it still causes real incidents. The embargo rule compares the time of the request with embargo_until, and either side can go wrong. The time of the request must come from the service's own clock, kept synchronized, never from a timestamp in the request, which the sender controls.

The embargo itself needs a time zone. The regatta result is announced at 10:00 in the festival's local time, four hours behind UTC in June. If the rights desk types "10:00" and the database stores it without a zone, a server running on UTC reads it as 10:00 UTC, and the photo is released four hours early. The Gazette stores every embargo in UTC with the zone written out, and converts to local time only for display:

entered:  14 June 2026, 10:00, festival local time
meaning:  2026-06-14T10:00:00-04:00
stored:   2026-06-14T14:00:00Z

That stored value is the 14:00 UTC embargo that refused Omar's early download of the regatta photo in Writing rules with attributes.

Place is weaker evidence still. The country of a request is usually derived from its IP address, by looking the address up in a database that maps address ranges to locations. The mapping is approximate and sometimes simply wrong. Mobile networks can route traffic through another country, a VPN moves an apparent location in seconds, and Omar covering an away match really is somewhere else. The licensing requirement compares a photo's license_regions with this country. That is a reasonable guard against honest mistakes, such as a colleague abroad downloading a wire photo the Gazette may not use there, but it will not stop anyone who wants to get around it. A country derived from an IP address should never be the only control on anything that matters.

The network has lost most of its meaning too. "On the newsroom network" once meant sitting in the building at a newsroom desk. Now Omar works from home over a VPN, from the café without one, and from the press box on a phone. A laptop on the VPN may be infected, and a laptop at the café may be perfectly safe. Network membership says where traffic entered, not who sent it or from what device, so it can suggest that a request deserves a closer look but cannot vouch for one.

Devices

The device condition in the download rule is the strongest environment evidence the Gazette has, because something actually checked the device. The Gazette's laptops are enrolled in device management, which installs updates, requires disk encryption and a screen lock, and can wipe a machine that is lost. When the rule asks whether a device is managed, it is really asking device management, and the decision has to trust that system's answer.

That answer must reach the decision in a way the device cannot fake. A request header such as Device-Managed: true is worthless as evidence, because any browser extension, script or tool can set it. Enrollment usually places a certificate on the device instead, with its private key protected by the device's hardware where possible. The device proves it holds that key when it connects, or presents a signed statement of its state, and the service verifies the proof and then checks the device's current standing. A laptop reported lost an hour ago should stop counting as managed, which makes this another attribute that needs to be fresh.

Unmanaged does not mean malicious. Omar's personal laptop may be better maintained than some of the Gazette's own. What the rule lacks is evidence, not proof of danger, and that difference should shape the response. Managed does not mean safe either. It means known and configured, which is why the Gazette combines it with other signals instead of letting it settle everything alone.

Risk signals

Many services receive a risk score with each sign-in or session, from a system that weighs signals such as an unfamiliar device, an address with a poor reputation, or sign-ins from two distant places within an hour. A score of high is useful information. It is also someone else's judgment, made with inputs and thresholds the photo service cannot see, and it is wrong in both directions: travelers trip it, and careful attackers avoid it.

The Gazette therefore combines the score with other attributes rather than treating it as the truth. On a managed newsroom laptop, a high score alone does not block a download, because device management already vouches for the machine. On an unmanaged laptop, where nothing else vouches for it, a high score is enough to refuse the full-resolution file. It also matters what the score measured and when. A score computed at sign-in at 08:10 says nothing about a connection that changed at 15:00.

Asking for more instead of saying no

Back at the café, a flat refusal has a cost. Omar still needs the photo, and people who are blocked find workarounds: a screenshot of the preview, or a colleague in the newsroom who downloads the file and emails it. The decision can do better by asking what evidence would be enough.

The Gazette decides that viewing photos needs no managed device, so Omar can see photo 9001 and its caption from anywhere. For the full-resolution file on an unmanaged device, it accepts a different kind of evidence: a passkey sign-in within the last 15 minutes, provided the risk score is low. The policy gains a second route to the same permission, while the embargo forbid stays as it was:

permit photo.download
  when "picture-editor" in subject.roles
   and resource.status in ["draft", "approved"]
   and environment.device.managed is true

permit photo.download
  when "picture-editor" in subject.roles
   and resource.status in ["draft", "approved"]
   and environment.sign_in.method is "passkey"
   and environment.sign_in.time is within 15 minutes
   and environment.risk is "low"

When a request fails only because the sign-in is too old or too weak, the decision can report that, and the application asks Omar to sign in again with a passkey instead of showing an error. This is step-up authentication, described in Authentication policy and SSO. When Omar returns, the same request is evaluated again with the new sign-in. Here is the same download of photo 9001 at 15:00 UTC under three contexts:

Each of these decisions holds for one request. Context changes during a session: a laptop falls out of compliance, a risk score rises, or Omar walks from the newsroom to the café. Because the Gazette checks every request, the next decision sees the new attributes, as long as they are fresh enough, which is the trade the previous lesson described. Some systems go further and revisit decisions while a session is still open. When device management or the risk system reports a change, the service ends the session or asks for a new sign-in straight away, instead of waiting for the next request or for the token to expire. This is often called continuous evaluation, and Revoking access and sharing security events follows how one system tells another that something has changed.