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 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Plan a cloud deployment
Distinguish reaching a service from being allowed to use its data or actions.
See the 7-concept route
For engineers moving an application into a customer environment. This route introduces the concepts before provider setup and deeper labs.
- 01The environmentLocate the application, its data and the responsibilities shared with a cloud provider.
- 02NetworkingTrace how a request reaches a service before choosing public or private access.
- 03IdentityYou are here
- 04Google CloudApply those boundaries to Google Cloud projects, regions and instances.
- 05AzureCompare how Azure subscriptions, resource groups and networks organize the same workload.
- 06AWSCompare AWS accounts, regions, Availability Zones and instances without assuming the services are interchangeable.
- 07Private inferenceDecide which model-serving responsibilities become yours when you operate the runtime.
Bookmark this page to return to this concept. The number shows your place in the reading route; it is not an assessment result.
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.
UNDERSTAND THE SYSTEM
Follow a document request through its access checks
A building badge identifies you; permission opens a particular room. Follow the same distinction in software: a verified caller, one active organization and a document read. These are authored lab cases with real local query behavior and a supplied identity fixture.
Read the connections in plain English
- 01Proposed request → Access check
Treat the requested document and optional tenant claim as untrusted input.
- 02Trusted context → Access check
Use the verified active workspace, never a tenant selected by the model.
- 03Access check → Document query
Bind the document ID and trusted scope as query parameters.
- 04Current read grant → Document query
Join the document to the current caller's read grant in the same organization.
- 05Document query → Returned content
No matching row means no document content is returned.
- 06Access check → Returned content
Missing identity or a mismatched scope can stop before a document query.
Check your understanding: A valid North login asks for North/P-8. Must the application return it?
No. The caller still needs permission for that document and action. The restricted lab case has a valid supplied identity and matching organization, but its scoped query returns zero rows. Enforce that boundary before data enters model context.
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.
Useful foundations
Open a definition and diagram here. Your lesson stays in place.
A software contractWhat is an API?
QUICK REFERENCE / 101
What is an API?
An application programming interface (API) is an agreed way for one piece of software to use another. It specifies operations, inputs, outputs and errors. Some APIs are local functions; a web API exchanges requests and responses across a network.
An agent becomes useful through connections to business systems. Those connections need clear contracts and failure behavior.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
Two organizations both have a machine called Pump-7. A lookup must use the signed-in organization, not whichever organization the model supplies.
UNDERSTAND THE SYSTEM
Follow a document request through its access checks
A building badge identifies you; permission opens a particular room. Follow the same distinction in software: a verified caller, one active organization and a document read. These are authored lab cases with real local query behavior and a supplied identity fixture.
See what moves and why.
Read the connections in plain English
- 01Proposed request → Access check
Treat the requested document and optional tenant claim as untrusted input.
- 02Trusted context → Access check
Use the verified active workspace, never a tenant selected by the model.
- 03Access check → Document query
Bind the document ID and trusted scope as query parameters.
- 04Current read grant → Document query
Join the document to the current caller's read grant in the same organization.
- 05Document query → Returned content
No matching row means no document content is returned.
- 06Access check → Returned content
Missing identity or a mismatched scope can stop before a document query.
Check your understanding: A valid North login asks for North/P-8. Must the application return it?
No. The caller still needs permission for that document and action. The restricted lab case has a valid supplied identity and matching organization, but its scoped query returns zero rows. Enforce that boundary before data enters model context.
Work through it, step by step.
Establish the caller
Resolve the server-side identity from a verified credential or session.
What you have now: A trusted principal
Check the operation
Apply resource and action policy to the requested machine and operation.
What you have now: A scoped permission decision
Constrain the data
Read and write through a boundary that enforces the same tenant scope. Log decisions without credentials.
What you have now: An isolated result
FROM RECOGNITION TO REASONING
Predict and run five document-access cases.
- 01
Compare a permitted read, missing caller context and a request claiming another organization.
- 02
Read a restricted record in the correct organization, then remove an existing read grant and repeat a request.
- 03
Change one input in each of two separate lab copies and explain the query and returned-row counts.
Five predictions, actual query results, two changed-copy comparisons and a diagram separating trusted context from tool arguments.
Compare your reasoning when you are ready
A valid login and matching tenant do not grant every document. The local query also checks the current caller's read permission before returning content. Identity verification is supplied as a fixture; no login or model is implemented.
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.