# adding grants to your own entity from another file

> A `security { }` block lives inside its entity's declaration, so a build shape that ships a subset of your files cannot add a grant — the entity is in a file both shapes need. A `partial entity` over your OWN entity solves it: a second file states extra access for an entity declared elsewhere. The grants add; they can never relax what the declaration denied, because the runtime folds policy rows so `allow` rules OR while the defaults take the more restrictive answer.

<!-- id: security-partial-security-on-your-own-entity · area: security · stability: preview · html: https://osysharp.com/reference/security/partial-security-on-your-own-entity/ -->

## Summary        {#summary}
A grant is written **inside** its entity's `security { }` block. That is the right default — one entity, one place
to read its rules — and it has one case it cannot serve: an app that builds into **more than one shape**, where some
grants belong to only one of them.

`partial entity X { security { … } }` over the app's **own** entity is the answer. A second file states extra access
for an entity declared elsewhere, and the file can be one a given build never compiles.

## Signature      {#signature}
```osy syntax
// shared file — every shape compiles this one
entity Order {
  [MaxLength(40)] string Code;
  security { allow read when IsAuthenticated; }
}

// shape-specific file — only some builds compile this one
partial entity Order {
  security { allow read, update when IsZoneAgent; }
}
```

## Description    {#description}

### Why a folder cannot do this on its own   {#why}
Splitting an app by build shape is ordinary file selection: put the files one shape does not want in a subfolder and
let its manifest glob non-recursively. Whole declarations move cleanly that way — an entity, a function, a page.

A **grant** does not, and the reason is structural rather than awkward. The grant lives inside the entity's
declaration, and the entities that need shape-specific access are exactly the ones **both** shapes need. There is no
file you can put the grant in that the smaller build will not read, because the grant is not in a file of its own —
it is three lines inside a declaration that has to be shared.

### What adds, and what cannot   {#what-adds}
An entity accumulates **several** policy rows. Its own declaration writes one; a partial writes another; capability
ownership and derived access write more. The runtime folds them with two different rules, and the asymmetry is the
whole safety story:

- **`allow` rules OR together.** A partial can grant access the declaration did not.
- **The operation DEFAULTS take the more restrictive answer.** A second policy may only ever narrow what another
  left open.

So a partial can **add** a grant and can never **relax** one. You do not have to read every file to know the floor:
the declaration's own block is the floor, and nothing in another file can lower it.

### One partial per entity   {#one-partial}
Two `partial entity Order` blocks in one app are refused. Each would rebuild the same policy row wholesale, so the
second would silently win and the first's rules would vanish — a refusal is better than picking. Put the shape's
grants in one block.

### A partial states security and nothing else   {#security-only}
A partial may carry a `security { }` block and `[SuppressWarning]`. It may not declare members or invariants. To
relate your entity to something else, declare the reference on the entity that should carry it.

## Examples       {#examples}

```osy title="a grant only one build ships" test app=security-partial-own-entity
[Role] enum AppRole { Authenticator, Member }
[Principal] entity User {
  [Unique, MaxLength(200)] string Email;
  security { allow read when IsAuthenticated; }
}
[RoleGrant] entity RoleGrant { User Grantee; [Required] AppRole Level;
  security { allow read when IsAuthenticated; } }
policy IsMember => RoleGrant.Any(g => g.Grantee == user && g.Level == AppRole.Member);

entity Order {
  [MaxLength(40)] string Code;
  security { allow read when IsAuthenticated; }
}

// In a real app this block lives in a file the smaller build does not glob.
partial entity Order {
  security { allow read, update when IsMember; }
}
```

An `Order` is readable by any signed-in user in **both** shapes, and updatable by a member only in the shape that
compiles the second file. The `allow read` in the partial is redundant beside the declaration's — harmless, because
the rules OR.

## See also       {#see-also}
- [security { }](https://osysharp.com/reference/security/entity-security/) — the `security { }` block itself
- [capability rows that belong to a user](https://osysharp.com/reference/security/capability-row-ownership/) — a partial over an entity a `using` brought in, which is the other use
- [[Authority]](https://osysharp.com/reference/security/contribution-authority/) — what a package allows an app to state about its entities
- [secure by default (deny-all)](https://osysharp.com/reference/security/secure-by-default/) — why an entity with no block at all is denied