EXPLORE YOUR NEXT CHAPTER
Thesis: Least-Privilege Tool Use for Coding Agents
Knightec Group Sweden
Source: Headcount Labs · original listing ↗
Job data: Headcount Labs, ODbL 1.0. Job descriptions belong to their employers.
Source date: 2026-10-14
About this role
Join us for your thesis work! Gain hands-on experience, work on real projects, and develop your skills in a supportive and innovative environment! High Level Description Coding agents can read a repository, call package registries, and edit CI configuration. Those capabilities make them useful, and they also make a loose default risky: an agent can change the workflow that checks it or pull code from a source the project never intended. This thesis tests least-privilege setups for that tool use, and measures how often a tight policy blocks ordinary work versus risky calls. Who are we looking for? • Bachelor’s/master’s student Computer Engineering with an interest in software security, developer tooling, and CI/CD. • Graduation in June 2027 • Fluency in Swedish, both written and spoken • Fluency in English, both written and spoken Purpose This thesis investigates how least-privilege controls can be applied to the tools a coding agent is allowed to use, and whether those controls can be tight enough to matter without stopping ordinary development work. The aim is to move past a single “allow the tools” default by: • Identifying which capabilities common coding-agent tasks need, and which can stay off by default • Separating high-impact actions, such as repository write, package installation, and CI-configuration changes, so one task does not imply the others • Comparing broader and tighter policies on the same work, including cases where a human checkpoint is more appropriate than a silent allow or a hard denial • Measuring both sides of the trade-off: legitimate work that is blocked or delayed, and pre-agreed risky action classes that a policy allows, denies, or escalates • Presenting allows and denials in a form a developer can act on, for example in a CI log or a pull-request comment A proof-of-concept policy layer should be implemented in a small lab and evaluated against a broad baseline. The choice of agent runtime, CI host, language ecosystems, policy mechanisms, and task set is part of the work, and should be agreed with the supervisor. Finding new ways to bypass the sandbox is out of scope. In this thesis, investigate these questions: • Necessary permissions. Which tools do common coding-agent tasks actually use, and which can stay off by default? • Separation of capabilities. How should repository write, package installation, and CI edits be split so one task does not imply the others? • Blocked work. How often does a tighter policy stop a legitimate task, and is the block a hard denial or an approval step? • Risky-call coverage. How often do the same policies deny pre-agreed risky classes, such as secret access, CI permission changes, and fetches outside allowed sources? • Developer cost. How much extra friction — prompts, approvals, and time — does a tight policy add compared with a broad baseline? Workflow fit. Can allows and denials be shown in a way a developer will use? Scope and Limitations Scope: • Investigating least-privilege policies for coding-agent tool use, rather than agent capability in general. • Implementing a proof-of-concept policy layer in a small, controlled lab. • Comparing policies on ordinary maintenance tasks and on a fixed scoring set of risky action classes, agreed in advance. • Evaluating the result as a method and a prototype, not as a production product. Limitations: • The study does not aim to produce a production-ready control plane. • Results are tied to the agent, forge, and ecosystems chosen for the lab, and may not generalize. • The scoring set measures the policies under study. It is not a claim that a policy is safe in general. • Model poisoning, new sandbox bypasses, and compromised build infrastructure are out of scope. • No production credentials are used in the agent environment. An Exciting Journey with Knightec Group Semcon and Knightec have joined forces as Knightec Group. Together, we are Northern Europe’s leading strategic partner in product and digital service development. With a unique combination of cross-functional expertise and a holistic business understanding, we help our clients realize their strategies – from idea to complete solution. Practical Information This is a thesis position, located at our office in Sundsvall . Start date January or March 2027. Please submit your application as soon as possible, but no later than 2026-11-30 . If you have any questions, you are welcome to contact johanna.edstrom@knightec.se . Note that due to GDPR, we only accept applications through our careers page. Business unit sweden Thesis Sweden Role Bachelor thesis Location Sundsvall