LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 48 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
- 01Establish the caller
- 02Check the operation
- 03Constrain the data
Access-control concepts
Authentication, authorization and tenant isolation
Authentication establishes who or what is calling. Authorization decides what that identity may do. Tenant isolation keeps one organization's data and actions separate from another's. An agent's tool call is a proposed action, not proof of any of these permissions.
An FDE must protect real organizational boundaries even when prompts, retrieved text or tool arguments are hostile.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
A building badge identifies you. The permission on a particular room determines whether you can enter. A valid badge does not open every customer's office.
Never let a model choose its own tenant, role or authority. Bind those values to trusted server context and recheck permission at the data or action boundary.
Words worth knowing
- Principal
- A person or workload identity.
- Least privilege
- Granting only the permissions required for a job.
- Tenant
- An organization or other isolation boundary in a shared service.
ONE EXAMPLE / FICTIONAL CASE
Watch the work take shape.
Two organizations both have a machine called Pump-7. A lookup must use the signed-in organization, not whichever organization the model supplies.
- 01Establish the caller
- 02Check the operation
- 03Constrain the data
Establish the caller
Resolve the server-side identity from a verified credential or session.
A trusted principalFROM RECOGNITION TO REASONING
Write a cross-organization rejection case.
- 01
Create two fictional organizations with the same machine name.
- 02
Ask the first caller to read the second organization's record.
- 03
Explain which server check rejects it even if the model insists.
A denied case alongside an authorized case.
Compare your reasoning when you are ready
Filtering a model's final words is too late if unauthorized data already entered the prompt. Enforce access before retrieval and again before any write.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
Never let a model choose its own tenant, role or authority. Bind those values to trusted server context and recheck permission at the data or action boundary.
Academy lessons use your existing training access. Free guides stay open.